OAuth2.0原理和验证流程分析

Posted 2023-03-09

参考技术A

第三方授权就是，委托第三方来对既定的用户进行鉴定，鉴定成功之后，下发信任凭证，信任凭证和用户挂钩，同时可以使用此凭证来去第三方平台，获得该用户开放的部分信息.
直白的说，就是将用户授权的工作交给第三方来做，而自己只维护信任凭证，并且获取用户信息。就像我们的QQ和微博一样，你在逛各大论坛的时候，总会有一种途径就是第三方的App登陆。显然这种验证是要在第三方做的，而论坛只需要维护一个token，并且可以获取你的个人信息，然而没什么软用。你如果想用部分功能，还是得注册，因为你相当于论坛只是一个有部分信息的游客，而没有成为它的用户，这种手段可以看成是提高自己访问量或转化率的一种手段吧。其实这种授权方案不一样只用在互联网，部分企业级的网站做资源的共享访问也是这么做的。比如两个网站合作，A站点账户可以登陆B站点，B站点账户可以登陆A站点，这样A站点就能拿到B站点相关资源，反过来也是。就做到了资源共享。
那么这种授权是怎么做的呢？到底安全不安全？那么可能就要引出OAuth协议了。

首先OAuth只是一个授权协议，不是一个实现或是一个中间件。
OAuth1于2007年10月建立，之后又在2009年6月重新修订和发布 http://oauth.net/core/1.0a/
OAuth1.0授权流程是什么？

流程很复杂，因为OAuth需要保证授权码和Token在传输的时候不被截取和篡改，所以使用了很多签名反复的验证。
OAuth1.0的问题：
反复的签名，开放平台本来就面对开发者，但是反复的签名导致开发的流程太过于复杂。
没有引入回跳地址的判断，导致会跳可能会篡改，这样授权码和Token会被Hack掉（1.0a的时候修复了这个漏洞）。
授权流程过于单一化。

OAuth2.0的引入：
抽象验证流程
由于OAuth1过于复杂，之后对OAuth进行了改造引入了Oauth2.0。OAuth的授权过程如下：

(A) 客户端从资源拥有者那里请求授权。授权请求能够直接发送给资源拥有者，或者间接地通过授权服务器这样的中介，而后者更为可取。

(B) 客户端收到一个访问许可，它代表由资源服务器提供的授权。

(C) 客户端使用它自己的私有证书到授权服务器上验证，并出示访问许可，来请求一个访问令牌。

(D) 授权服务器验证客户端私有证书和访问许可的有效性，如果验证通过则分发一个访问令牌。

(E) 客户端通过出示访问令牌向资源服务器请求受保护资源。

(F) 资源服务器验证访问令牌的有效性，如果验证通过则响应这个资源请求。

上面只是一个抽象的验证流程，根据上面的抽象流程演化出四种验证模式：
授权码模式
授权码模式和上述的 抽象验证模式流程比较相似：

(A) web客户端通过将终端用户的user-agent重定向到授权服务器来发起这个流程。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向URI，在访问被许可（或被拒绝）后授权服务器会重新将终端用户引导回这个URI。

(B) 授权服务器验证终端用户（借助于user-agent），并确定终端用户是否许可客户端的访问请求。

(C) 假定终端用户许可了这次访问，授权服务器会将user-agent重定向到之前提供的重定向URI上去。授权服务器为客户端传回一个授权码做获取访问令牌之用。

(D) 客户端通过验证并传入上一步取得的授权码从授权服务器请求一个访问令牌。（需要带上ClientId和Secret，ClientId和Secret是通过平台授予）

(E) 授权服务器验证客户端私有证书和授权码的有效性并返回访问令牌。

授权码模式（implicit grant type）
User-Agent子态适用于客户端不能保存客户端私有证书的App（纯客户端App，无Server参与）。因为可纯客户端的程序不能保存密钥

(A) 客户端将user-agent引导到终端用户授权endpoint。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向URI，在访问被许可（或被拒绝）后授权服务器会重新将终端用户引导回这个URI。

(B) 授权服务器验证终端用户（通过user-agent）并确认终端用户是许可还是拒绝了客户端的访问请求。

(C) 如果终端用户许可了这次访问，那么授权服务器会将user-agent引导到之前提供的重定向URI。重定向URI会在URI片断译者注：URI片断是指URI中#号之后的内容中包含访问令牌。

(D) user-agent响应重定向指令，向web服务器发送不包含URI片断的请求。user-agent在本地保存URI片断。

(E) web服务器返回一个web页面（通常是嵌入了脚本的html网页），这个页面能够访问完整的重定向URI，它包含了由user-agent保存的URI片断，同时这个页面能够将包含在URI片断中的访问令牌（和其它参数）提取出来。

(F) user-agent在本地执行由web服务器提供的脚本，该脚本提取出访问令牌并将它传递给客户端。

密码模式
密码模式就是将密码托管给第三方App，但是必须要保证第三方App高度可信。

（A）用户向客户端提供用户名和密码。

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

（C）认证服务器确认无误后，向客户端提供访问令牌。

客户端模式
这种模式不需要终端用户的参与，只是Client和Server端的交互。通常只用于Client状态的获取。

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。

（B）认证服务器确认无误后，向客户端提供访问令牌。

授权流程
这里以授权码方式流程说明，主要流程分为两步，获取授权码和通过授权码获取资源票据：

（A）用户访问客户端，后者将前者导向认证服务器。

（B）用户选择是否给予客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

A步骤中，客户端申请认证的URI，包含以下参数：

response_type：表示授权类型，必选项，此处的值固定为"code"
client_id：表示客户端的ID，必选项
redirect_uri：表示重定向URI，可选项
scope：表示申请的权限范围，可选项
state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

C步骤中，服务器回应客户端的URI，包含以下参数：
code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：
grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。
code：表示上一步获得的授权码，必选项。
redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
client_id：表示客户端ID，必选项。

E步骤中，认证服务器发送的HTTP回复，包含以下参数：
access_token：表示访问令牌，必选项。
token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

资源访问过程：
http://localhost:8082/oauth/server/resource/uname.do?access_token=233730a3d4cdc1af64f78fa80bc13c6e
此处主要由资源服务方实现，对于access_token进行校验。

token过期刷新过程：
客户端使用“refresh_token”访问许可类型和下列参数传入刷新令牌：
refresh_token：
必需参数。与待刷新的访问令牌相关联的刷新令牌。
grant_type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&refresh_token=n4E9O119d
授权服务器必须验证客户端私有证书（如果存在），验证刷新令牌是否有效，以及验证资源拥有者的授权是否仍然有效。如果请求有效，授权服务器则发布一个访问令牌响应，原来的Token失效。以后访问必须使用新Token。

OAuth2看上去很美好，但是细心观察其实还是有一些漏洞的。

参考资料：
http://blog.csdn.net/seccloud/article/details/8192707
http://www.justwinit.cn/post/8138/
https://blog.yorkxin.org/2013/09/30/oauth2-1-introduction
人人网OAuth历程: http://www.infoq.com/cn/presentations/dx-renren-authentication-authorization/