OAuth2.0协议

分手后的思念是犯贱 2022-07-13 12:50 340阅读 0赞

OAuth的参与实体至少有如下三个：

**· RO** (resource owner): 资源所有者，对资源具有授权能力的人。如上文中的用户Alice。

**· RS** (resource server): 资源服务器，它存储资源，并处理对资源的访问请求。如Google资源服务器，它所保管的资源就是用户Alice的照片。

**· Client**: 第三方应用，它获得RO的授权后便可以去访问RO的资源。如网易印像服务。

此外，为了支持开放授权功能以及更好地描述开放授权协议，OAuth引入了第四个参与实体：

**· AS** (authorization server): 授权服务器，它认证RO的身份，为RO提供授权审批流程，并最终颁发授权令牌(Access Token)。读者请注意，为了便于协议的描述，这里只是在逻辑上把AS与RS区分开来；在物理上，AS与RS的功能可以由同一个服务器来提供服务。

**2.2 授权类型**

在开放授权中，第三方应用(Client)可能是一个Web站点，也可能是在浏览器中运行的一段JavaScript代码，还可能是安装在本地的一个应用程序。这些第三方应用都有各自的安全特性。对于Web站点来说，它与RO浏览器是分离的，它可以自己保存协议中的敏感数据，这些密钥可以不暴露给RO；对于JavaScript代码和本地安全的应用程序来说，它本来就运行在RO的浏览器中，RO是可以访问到Client在协议中的敏感数据。

OAuth为了支持这些不同类型的第三方应用，提出了多种授权类型，如授权码 (Authorization Code Grant)、隐式授权 (Implicit Grant)、RO凭证授权 (Resource Owner Password Credentials Grant)、Client凭证授权 (Client Credentials Grant)。由于本文旨在帮助用户理解OAuth协议，所以我将先介绍这些授权类型的基本思路，然后选择其中最核心、最难理解、也是最广泛使用的一种授权类型——“授权码”，进行深入的介绍。

**2.3 OAuth协议 - 基本思路**  
  
![20140520223105125][]  
\[Figure 1: Abstract Protocol Flow\]  
  
如图1所示，协议的基本流程如下：

(1) Client请求RO的授权，请求中一般包含：要访问的资源路径，操作类型，Client的身份等信息。

(2) RO批准授权，并将“授权证据”发送给Client。至于RO如何批准，这个是协议之外的事情。典型的做法是，AS提供授权审批界面，让RO显式批准。这个可以参考下一节实例化分析中的描述。

(3) Client向AS请求“访问令牌(Access Token)”。此时，Client需向AS提供RO的“授权证据”，以及Client自己身份的凭证。

(4) AS验证通过后，向Client返回“访问令牌”。访问令牌也有多种类型，若为bearer类型，那么谁持有访问令牌，谁就能访问资源。

(5) Client携带“访问令牌”访问RS上的资源。在令牌的有效期内，Client可以多次携带令牌去访问资源。

(6) RS验证令牌的有效性，比如是否伪造、是否越权、是否过期，验证通过后，才能提供服务。

**2.4 授权码类型的开放授权**  
  
![20140520222934390][]  
  
\[Figure 2: Authorization Code Flow\]  
  
如图2所示，授权码类型的开放授权协议流程描述如下：

(1) Client初始化协议的执行流程。首先通过HTTP 302来重定向RO用户代理到AS。Client在redirect\_uri中应包含如下参数：client\_id, scope (描述被访问的资源), redirect\_uri (即Client的URI), state (用于抵制CSRF攻击). 此外，请求中还可以包含access\_type和approval\_prompt参数。当approval\_prompt=force时，AS将提供交互页面，要求RO必须显式地批准（或拒绝）Client的此次请求。如果没有approval\_prompt参数，则默认为RO批准此次请求。当access\_type=offline时，AS将在颁发access\_token时，同时还会颁发一个refresh\_token。因为access\_token的有效期较短（如3600秒），为了优化协议执行流程，offline方式将允许Client直接持refresh\_token来换取一个新的access\_token。

(2) AS认证RO身份，并提供页面供RO决定是否批准或拒绝Client的此次请求（当approval\_prompt=force时）。

(3) 若请求被批准，AS使用步骤(1)中Client提供的redirect\_uri重定向RO用户代理到Client。redirect\_uri须包含authorization\_code，以及步骤1中Client提供的state。若请求被拒绝，AS将通过redirect\_uri返回相应的错误信息。

(4) Client拿authorization\_code去访问AS以交换所需的access\_token。Client请求信息中应包含用于认证Client身份所需的认证数据，以及上一步请求authorization\_code时所用的redirect\_uri。

(5) AS在收到authorization\_code时需要验证Client的身份，并验证收到的redirect\_uri与第3步请求authorization\_code时所使用的redirect\_uri相匹配。如果验证通过，AS将返回access\_token，以及refresh\_token（若access\_type=offline）。  
  
如果读者对这个流程的细节不甚清楚，那么可以先看第3节的一个实例化描述，然后再回来看这部分内容。  
  
**3. OAuth协议实例化描述**  
  
下面我以实例化方式来帮助读者理解授权码类型的授权协议的运行过程。假设:   
(1) Alice有一个有效的Google帐号；  
(2) Facebook.com已经在Google Authorization Server上注册了Client身份，已经获得(client\_id, client\_secret)，注意client\_secret是Client与AS之间的一个共享密钥。  
(3) Alice想授权Facebook.com查看她的联系人列表(https://www.google.com/m8/feeds)。  
  
图3展示了Alice、Facebook.com、Google资源服务器、以及Google OAuth授权服务器之间的协议运行过程。  
  
![20140520223129015][]  
\[Figure 3: An Instance of Authorization Code Flow\]    
//若字体无法看清，请单击右键->选择查看原图

协议所涉及到的细节都已经在图3上了，所以不打算再做详细介绍了。若看懂了此图，OAuth2.0就理解了。

读者请注意，在步骤(4)中，Client需要拿“授权码”去换“授权令牌”时，Client需要向AS证明自己的身份，即证明自己就是步骤(2)中Alice批准授权时的Grantee。这个身份证明的方法主要有两种（图3中使用了第1种）：  
(1) 通过https直接将client\_secret发送给AS，因为client\_secret是由Client与AS所共享，所以只要传送client\_secret的信道安全即可。  
(2) 通过消息认证码来认证Client身份，典型的算法有HMAC-SHA1。在这种方式下，Client无需传送client\_secret，只需发送消息请求的signature即可。由于不需要向AS传递敏感数据，所以它只需要使用http即可。

此外，** **在步骤(2)中，Google授权服务器需要认证Alice的RO身份，并提供授权界面给Alice进行授权审批。今天Google提供的实例如图4、图5所示，仅供读者理解OAuth这种“现场授权”或"在线授权"的含义。

![20140520223145421][]  
\[Figure 4: RO's Identity Authentication\]  
  
![20140520223159843][]  
\[Figure 5: RO's Authorization Decision\]  
  
**4. OAuth设计上的安全性考虑  
  
4.1 为何引入authorization\_code？**  
  
协议设计中，为什么要使用authorization\_code来交换access\_token？这是读者容易想到的一个问题。也就是说，在协议的第3步，为什么不直接将access\_token通过重定向方式返回给Client呢？比如:  
  
HTTP/1.1 302  
Location:  
https://www.facebook.com/?access\_token=ya29.AHES6ZSXVKYTW2VAGZtnMjD&token\_type=Bearer&expires\_in=3600  
  
如果直接返回access\_token，协议将变得更加简洁，而且少一次Client与AS之间的交互，性能也更优。那为何不这么设计呢？协议文档\[1\]中并没有给出这样设计的理由，但也不难分析：

> (1) 浏览器的redirect\_uri是一个不安全信道，此方式不适合于传递敏感数据（如access\_token）。因为uri可能通过HTTP referrer被传递给其它恶意站点，也可能存在于浏览器cacher或log文件中，这就给攻击者盗取access\_token带来了很多机会。另外，此协议也不应该假设RO用户代理的行为是可信赖的，因为RO的浏览器可能早已被攻击者植入了跨站脚本用来监听access\_token。因此，access\_token通过RO的用户代理传递给Client，会显著扩大access\_token被泄露的风险。 但authorization\_code可以通过redirect\_uri方式来传递，是因为authorization\_code并不像access\_token一样敏感。即使authorization\_code被泄露，攻击者也无法直接拿到access\_token，因为拿authorization\_code去交换access\_token是需要验证Client的真实身份。也就是说，除了Client之外，其他人拿authorization\_code是没有用的。 此外，access\_token应该只颁发给Client使用，其他任何主体（包括RO）都不应该获取access\_token。协议的设计应能保证Client是唯一有能力获取access\_token的主体。引入authorization\_code之后，便可以保证Client是access\_token的唯一持有人。当然，Client也是唯一的有义务需要保护access\_token不被泄露。
> 
> (2) 引入authorization\_code还会带来如下的好处。由于协议需要验证Client的身份，如果不引入authorization\_code，这个Client的身份认证只能通过第1步的redirect\_uri来传递。同样由于redirect\_uri是一个不安全信道，这就额外要求Client必须使用数字签名技术来进行身份认证，而不能用简单的密码或口令认证方式。引入authorization\_code之后，AS可以直接对Client进行身份认证（见步骤4和5），而且可以支持任意的Client认证方式（比如，简单地直接将Client端密钥发送给AS）。

在我们理解了上述安全性考虑之后，读者也许会有豁然开朗的感觉，懂得了引入authorization\_code的妙处。那么，是不是一定要引入authorization\_code才能解决这些安全问题呢？当然不是。笔者将会在另一篇博文给出一个直接返回access\_token的扩展授权类型解决方案，它在满足相同安全性的条件下，使协议更简洁，交互次数更少。  
  
**4.2 基于Web安全的考虑**  
  
OAuth协议设计不同于简单的网络安全协议的设计，因为OAuth需要考虑各种Web攻击，比如CSRF (Cross-Site Request Forgery), XSS (Cross Site Script), Clickjacking。要理解这些攻击原理，读者需要对浏览器安全（eg, Same Origin Policy, 同源策略）有基本理解。比如，在redirect\_uri中引入state参数就是从浏览器安全角度考虑的，有了它就可以抵制CSRF攻击。如果没有这个参数，攻击者便可以在redirect\_uri中注入攻击者提供的authorization\_code或access\_token，结果可能导致Client访问错误的资源（比如，将款项汇到一个错误的帐号）。  
  
基于Web安全的考虑，OAuth协议文档中已经有了比较全面的阐述，所以我不打算在此文中进行展开，有兴趣的读者请参考\[1\]。

[20140520223105125]: /images/20220713/938d54742b674a7e99638bd24c732d7f.png
[20140520222934390]: /images/20220713/9370002f55de49af99c82e0e9655bf61.png
[20140520223129015]: /images/20220713/e2b6b8bf68194461af7e435798f243ef.png
[20140520223145421]: /images/20220713/a22dafd01dfb4a94a69c7e4b4002a935.png
[20140520223159843]: /images/20220713/1b663dd166ff4d4a97ff49f3d9814bc4.png