IdServer
IdentityServer4
- 身份认证服务器(IdentityServer)
- IdentityServer是基于OpenID Connect协议标准的身份认证和授权程序,实现了OpenID Connect和OAuth2.0协议(一种向客户端颁发安全令牌的软件)
- 特性
- 认证服务
- 单点登录和登出
- API访问控制
- 联合网关
- 灵活定制
- 功能
- 保护资源
- 集中认证和授权
- 提供会话管理和单点登录
- 管理和验证客户端
- 向客户端颁发标识和访问令牌
- 验证令牌
- OAuth2.0和OpenID Connect?
- OAuth2.0
- OAuth2.0是一个开放授权标准,它允许用户让第三方应用访问该用户在某个服务的特定私有资源,但是不提供账号密码信息给第三方应用(不给账号和密码访问资源)
- OAuth2.0包含了四个角色
- Resource Owner:资源所有者
- Resource Server:资源服务器
- Client:第三方应用服务器
- Authorzation Server:授权服务器,管理Resource Owner,Resource Server和Client的三角关系的中间层
- OAuth2的授权流程
- Authorization Grant(授权许可)是一个代表资源所有者授权(访问受资源)的凭据,客户端用它来获取访问令牌
- OpenID Connect(OIDC)
- OIDC(Identity,Authentication)+OAuth2.0,在OAuth2上构建一个身份层,是一个基于OAuth2协议的身份认证标注协议,(OAuth2是一个授权协议,它无法提供完善的身份认证功能)OIDC使用OAuth2.0的授权服务器来为第三方客户端提供用户的身份认证,并把对应的身份认证信息传递给客户端,且适用于各种类型的客户端
- OIDC工作流程:
- RP发送一个认证请求给OP
- OP对EU进行身份认证,然后提供授权
- OP把ID Token和AccessToken(需要的话)返回给RP
- RP把Access Token发送一个请求Userinfo EndPoint
- Userinfo EndPoint返回EU的Claims
- OAuth2.0
- 用户(User)
- 使用已注册的客户端访问资源的人(Id4已经注册的用户)
- 客户端(Client)
- 客户端是向IdServer4请求令牌的软件,即可以通过身份认证令牌来验证识别用户身份,又可以通过授权令牌来访问服务器的资源。但客户端访问资源前需要先在IdServer4中注册(web、app、桌面应用、spa、服务器进程)
- 资源(Resources)
- 资源就是你想用IdServer4保护的东西,可以用户的身份数据或API资源。每个资源都有一个唯一的名称,客户端使用这个唯一的名称来访问哪一个资源(IdServer配置好哪个客户端访问哪个资源)
- 用户的身份信息实际有一组Claim组成,例如姓名,邮件地址等信息
- API资源就是客户端想要调用的功能,通常为Web API
- 身份令牌(ID Token)
- OIDC对OAuth2最主要的扩展就是提供了ID Token,来解决第三方客户端标识用户认证的问题
- ID Token是一个安全令牌,(由一组Cliams构成以及其他辅助的Cliams的JWT格式的数据结构组成。)表示认证过程的输出,是一个授权服务器提供的包含用户信息,还包含了用户的认证时间和认证方式。还可以包含额外的身份数据
- 访问令牌(Access Token)
- 访问令牌允许客户端访问某个API资源。客户端请求到访问令牌,然后使用这个令牌来访问API资源。访问令牌包含了客户端和用户的相关信息,API通过这些令牌信息来授予客户端的数据访问权限
- OAuth2提供了Access Token来解决授权第三方客户端访问受保护资源的问题;
- 刷新令牌(Refresh Token)
- Access Token(临时的,有有效期的)是客户端访问资源服务器的令牌,拥有这个令牌代表着得到用户的授权。Refresh Token是用来刷新Access Token的,传入Refresh Token和client_id,鉴权服务器验证通过后,返回一个新的access token。
- 案例:
http://xxx.xxx.com/refresh?refreshtoken=&client_id=
- 为了安全,OAuth2.0引入了两个措施:
- refresh token一定保存在客户端的服务器上,绝不能存放在狭义的客户端(例如移动APP、Pc端软件)上,调用refresh接口的时候,一定从服务器到服务器的访问。
- 引入client_secret机制,即每一个client_id对应一个client_secret。这个client_secret会在客户端申请client_id时,随着client_id一起分配给客户端。客户端必须把这个client_secret妥善保管在服务器上,刷新token时,需要验证这个client_secret
- 案例:
http://xxx.xxx.com/refresh?refreshtoken=&client_id=&client_secret=
- 链接: