在上一篇中,咱们IdentityServer4的说明,认识到是一个基于OpenID Connect协议标准的身份认证和受权程序,并简单的对基础知识的认识以及区别说明,从OAuth、OpenID、OpenID Connect以及JWT等进行对比区别说明。html
而在这一篇中,咱们主要对IdentityServer4中涉及使用的特定的相关术语进行说明。web
IdentityServer 是基于OpenID Connect协议标准的身份认证和受权程序,它实现了OpenID Connect 和 OAuth 2.0 协议。数据库
一样的角色,不一样的文档使用不一样的术语。在有些文档中,它(IdentityServer)可能会被叫作安全令牌服务器(security token service)、身份提供者(identity provider)、受权服务器(authorization server)、 标识提供方((IP-STS,什么是IP-STS)等等。json
可是它们都是同样的,都是向客户端发送安全令牌(security token),api
IdentityServer有许多功能:安全
用户是使用已注册的客户端访问资源的人。服务器
指在id4中已经注册的用户数据结构
客户端就是从identityserver请求令牌的软件,既能够经过身份认证令牌来验证识别用户身份,又能够经过受权令牌来访问服务端的资源。可是客户端首先必须在申请令牌前已经在identityserver服务中注册过。app
实际客户端不只能够是Web应用程序,app或桌面应用程序,SPA,服务器进程等。ide
客户端:web、app、桌面应用、SPA、服务器进程
资源就是你想用identityserver保护的东西,能够是用户的身份数据或者api资源。
每个资源都有一个惟一的名称,客户端使用这个惟一的名称来肯定想访问哪个资源
在访问以前,实际identityserver服务端已经配置好了哪一个客户端能够访问哪一个资源,因此你没必要理解为客户端只要指定名称他们就能够随便访问任何一个资源
用户的身份信息实际由一组claim组成,例如姓名或者邮件都会包含在身份信息中。
用户身份信息未来经过identityserver校验后都会返回给被调用的客户端
API资源就是客户端想要调用的功能——一般经过 Web API 来对 API 资源建模,但这不是必须的,以下说明:
一般以json或xml的格式返回给客户端,例如webapi,wcf,webservice,可使其余类型的格式,这个要看具体的使用场景了。
OIDC对OAuth2最主要的扩展就是提供了ID Token。来解决第三方客户端标识用户身份认证的问题。
OIDC的核心在于在OAuth2的受权流程中,一并提供用户的身份认证信息(ID Token)给到第三方客户端,ID Token使用JWT格式来包装,得益于JWT(JSON Web Token)的自包含性,紧凑性以及防篡改机制,使得ID Token能够安全的传递给第三方客户端程序而且容易被验证。此外还提供了UserInfo的接口,用户获取用户的更完整的信息。
ID Token是一个安全令牌,表示的是认证过程的输出,是一个受权服务器提供的包含用户信息,还包含了用户的认证时间和认证方式。身份令牌能够包含额外的身份数据。
由一组Cliams构成以及其余辅助的Cliams的JWT格式的数据结构组成。
ID Token的主要构成部分以下(使用OAuth2流程的OIDC)。
- iss = Issuer Identifier:必须。提供认证信息者的惟一标识。通常是一个https的url(不包含querystring和fragment部分)。
- sub = Subject Identifier:必须。iss提供的EU的标识,在iss范围内惟一。它会被RP用来标识惟一的用户。最长为255个ASCII个字符。
- aud = Audience(s):必须。标识ID Token的受众。必须包含OAuth2的client_id。
- exp = Expiration time:必须。过时时间,超过此时间的ID Token会做废再也不被验证经过。
- iat = Issued At Time:必须。JWT的构建的时间。
- auth_time = AuthenticationTime:EU完成认证的时间。若是RP发送AuthN请求的时候携带max_age的参数,则此Claim是必须的。
- nonce:RP发送请求的时候提供的随机字符串,用来减缓重放攻击,也能够来关联ID Token和RP自己的Session信息。
- acr = Authentication Context Class Reference:可选。表示一个认证上下文引用值,能够用来标识认证上下文类。
- amr = Authentication Methods References:可选。表示一组认证方法。
- azp = Authorized party:可选。结合aud使用。只有在被认证的一方和受众(aud)不一致时才使用此值,通常状况下不多使用。
ID Token一般状况下还会包含其余的Claims。
(毕竟上述claim中只有sub是和EU相关的,这在通常状况下是不够的,必须还须要EU的用户名,头像等其余的资料,OIDC提供了一组公共的cliams,请移步这里http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)。另外ID Token必须使用JWS进行签名和JWE加密,从而提供认证的完整性、不能否认性以及可选的保密性。
简而言之ID Token就是JWT格式的数据,包含一我的类用户的身份认证的信息,一个ID Token的例子以下:
访问令牌容许客户端访问某个 API 资源。客户端请求到访问令牌,而后使用这个令牌来访问 API资源。访问令牌包含了客户端和用户(若是有的话,这取决于业务是否须要,但一般没必要要)的相关信息,API经过这些令牌信息来授予客户端的数据访问权限。
OAuth2提供了Access Token来解决受权第三方客户端访问受保护资源的问题;
Access Token 是客户端访问资源服务器的令牌。拥有这个令牌表明着获得用户的受权。然而,这个受权应该是临时的,有必定有效期。这是由于,Access Token 在使用的过程当中可能会泄露。给 Access Token 限定一个较短的有效期能够下降因 Access Token 泄露而带来的风险。
然而引入了有效期以后,客户端使用起来就不那么方便了。每当 Access Token 过时,客户端就必须从新向用户索要受权。这样用户可能每隔几天,甚至天天都须要进行受权操做。这是一件很是影响用户体验的事情。但愿有一种方法,能够避免这种状况。
因而 Oauth2.0 引入了 Refresh Token 机制。Refresh Token 的做用是用来刷新 Access Token。鉴权服务器提供一个刷新接口,例如:
http://xxx.xxx.com/refresh?refreshtoken=&client_id=
传入 refresh token 和 client_id,鉴权服务器验证经过后,返回一个新的 access token。为了安全,Oauth2.0 引入了两个措施:
1,Oauth2.0 要求,refresh token 必定是保存在客户端的服务器上的,而毫不能存放在狭义的客户端(例如移动 app、PC端软件) 上。调用 refresh 接口的时候,必定是从服务器到服务器的访问;
2,Oauth2.0 引入了 client_secret 机制。即每个 client_id 都对应一个 client_secret。这个 client_secret 会在客户端申请 client_id 时,随 client_id 一块儿分配给客户端。客户端必须把 client_secret 妥善保管在服务器上,决不能泄露。刷新 access token 时,须要验证这个 client_secret。
因而,实际上的刷新接口应该是相似这样的:
http://xxx.xxx.com/refresh?refreshtoken=&client_id=&client_secret=
以上就是 Refresh Token 机制。 Refresh Token 的有效期很是长,会在用户受权时,随 Access Token 一块儿重定向到回调 url,传递给客户端。