因为首先access token不含有任何关于身份认证的信息; 其次access token的生命期可能会非常的长, 即使用户离开了它仍有可能有效, 它还有可能被用于无最终用户参与的情况; 还有一种情况就是access token可能会被其它的客户端应用借用. 所以, 无论客户端是如何得到的access token, 它都无法从access token里得到最终用户的信息以及最终用户的身份认证状态.
在OAuth2里, access token不是为客户端准备的, 它对于客户端应该是不透明的, 但是客户端也需要从access token得到一些用户信息. 实际上客户端应用只是access token的展示者, access token真正的目标观众是被保护的资源.
在OpenID Connect里, 这个第二个叫做ID Token, 它会和access token一同发送给客户端应用.
OpenID Connect
OpenID Connect是由OpenID基金会于2014年发布的一个开放标准, 简单的说就是, 它使用OAuth2来进行身份认证. OpenID Connect直接构建于OAuth2.0的基础之上, 与其兼容. 通常OpenID Connect是和OAuth2一同部署来使用的.
OpenID Connect的整体抽象流程如下图所示:
1. 依赖发(RP)发送请求到OpenID提供商(OP, 也就是身份提供商).
2. OpenID提供商验证最终用户的身份, 并获得了用户委派的授权
3. OpenID提供商返回响应, 里面带着ID Token, 也通常带着Access Token.
4. 依赖方现在可以使用Access Token发送请求到用户信息的端点.
5. 用户信息端点返回用户的声明(claims, 相当于是用户的信息).
OpenID Connect的ID Token 和用户信息端点以后在使用Identity Server 4的时候在进行介绍.
身份认证
OpenID Connect 会负责身份认证这个动作, 也就是把最终用户登录到系统, 或者判断最终用户是否已经登录了. OpenID Connect会通过一种安全的方式从服务器把身份认证的结果返回给客户端, 这样客户端就可以依赖于它了. 也是因为这个原因, 客户端被称为了依赖方(RP). 这个身份认证的结果就是ID Token.
OpenID Connect身份认证有三个路径(三个流程, flow): Authorization Code 流程, Implicit 流程, Hybrid 流程.
Authorization Code Flow
在Authorization Code 流程里, 一个授权码(Authorization Code)会被返回给客户端. 这个授权码可以被直接用来交换ID Token和Access Token. 该流程也可以在客户端使用授权码兑换Access Token之前对其身份认证. 但是该流程要求客户端的身份认证动作在后台使用client id和secret来获得tokens, 这样就不会把tokens暴露给浏览器或其它可访问浏览器的恶意应用了.
这种流程要求客户端应用可以安全的在它和授权服务器之间维护客户端的secret, 也就是说只适合这样的客户端应用.
它还适合于长时间的访问(通过refresh token).
Authorization Code流程的授权码来自于授权端点, 而所有的tokens都来自于Token端点.
Authorization Code流程的步骤如下:
客户端准备身份认证请求, 请求里包含所需的参数
客户端发送请求到授权服务器
授权服务器对最终用户进行身份认证
授权服务器获得最终用户的同意/授权
授权服务器把最终用户发送回客户端, 同时带着授权码
客户端使用授权码向Token端点请求一个响应
客户端接收到响应, 响应的body里面包含着ID Token 和 Access Token
客户端验证ID Token, 并获得用户的一些身份信息.
Implicit Flow
Implicit流程在请求token的时候不需要明确的客户端身份认证, 它使用重定向URI的方式来验证客户端的身份. 因为这一点, refresh token也就无法使用了, 这同样也不适合于长时间有效的access token.
在Implicit流程里, 所有的tokens都来自于授权端点, 而Token端点并没有用到.
该流程主要用于浏览器内的应用, Access Token和ID Token一同被直接返回给客户端. 因为这个原因, 这些tokens也会暴露于最终用户和可以访问该浏览器的其它应用了.
它并不适合于长时间的访问.
Implicit流程的步骤如下:
客户端准备身份认证请求, 请求里包含所需的参数
客户端发送请求到授权服务器
授权服务器对最终用户进行身份认证
授权服务器获得最终用户的同意/授权
授权服务器把最终用户发送回客户端, 同时带着ID Token. 如果也请求了Access Token的话, 那么Access Token也会一同返回.
客户端验证ID Token, 并获得用户的一些身份信息.
Hybrid Flow
Hybrid流程是前两者的混合, 在该流程里, 有一些tokens和授权码来自于授权端点, 而另外一些tokens则来自于Token端点.
该流程允许客户端立即使用ID Token, 并且只需要一次往返即可获得授权码.
这种流程也要求客户端应用可以安全的维护secret.
它也适合于长时间的访问.
Hybrid流程的步骤如下:
客户端准备身份认证请求, 请求里包含所需的参数
客户端发送请求到授权服务器
授权服务器对最终用户进行身份认证
授权服务器获得最终用户的同意/授权
授权服务器把最终用户发送回客户端, 同时带着授权码, 根据响应类型的不同, 也可能还带着一个或者多个其它的参数.
客户端使用授权码向Token端点请求一个响应
客户端接收到响应, 响应的body里面包含着ID Token 和 Access Token
客户端验证ID Token, 并获得用户的一些身份信息.