The OAuth 2.0 Authorization Protocol （第一章，基础概念）

OAuth的2.0授权协议
草案-IETF-OAuth - V2 – 22
摘要：OAuth的2.0授权协议允许第三方应用程序获取机会有限的HTTP服务，无论是以资源所有者的名义通过协调的批准资源所有者和HTTP服务互动，或通过允许第三方应用程序，以自己的名义获得的访问。
 
1简介
在传统的客户端 - 服务器的身份验证模型中，客户端使用资源所有者服务器上凭据（credentials） 进行身份验证来申请访问受限资源（受保护的资源）。 为了提供第三方应用程序访问受限制的资源，资源的所有者分享其凭据给第三方。 这将产生几个问题和限制：
 
a.  第三方的应用程序需要存储资源业主的凭据，以备将来使用，通常是一个明确的密码文本。
 
b.  服务器都必须支持密码认证，尽管创建密码是安全薄弱环节。
 
c.  第三方应用程序获得对资源所有者的受保护的资源过大的权限，让资源所有者没有能力限制周期或访问一个有限子集资源。
 
d.  资源所有者不能在没有撤销所有的第三方访问的情况下，撤销个别第三方的访问，而且必须改变自己的密码来做这样的事。
 
e.  折中的任何第三方的应用程序导致折中的最终用户的密码和所有的数据被该密码保护。
 
OAuth 定位这些问题是通过引入授权层和从资源所有者那里分离客户端的角色。  在OAuth中，客户端请求访问被资源所有者控制和资源服务器托管的资源，并发出了跟资源所有者不同的凭据集合。
客户端获得一个访问令牌，即一个一个字符串，表示一个具体范围，寿命和其他访问属性，而不是使用资源所有者的凭据来访问受保护资源。访问令牌被授权服务器批准资源的所有者颁发给第三方客户端。 客户端使用访问令牌访问资源服务器托管的受保护资源。
例如，最终用户（资源所有者）可以授予一个打印服务（客户端）访问她的存储在共享服务（资源服务器）里受保护相片，而不共享与打印服务相关的用户名和密码。相反，她直接用照片共享服务（授权服务器）验证信任的服务器，这些照片共享服务产生打印服务的特定代表的凭据（访问令牌）。
本规范是专为使用HTTP设计的。使用HTTP之外的其他任何传输协议的OAuth的是不确定的。
1.1         角色
 OAuth的定义四个角色：
resource owner资源的所有者： 
可以获得授权去访问受保护的资源的实体。这句很绕口，简单来说就是资源的所
有者，这个所有者是指当初上传或生成的那个所有者，并不是指服务器的所有者。
 
resource server资源服务器：  
 承载受保护资源的服务器，可以接收和响应使用access token（访问令牌）请求
受保护资源。
 
cilent客户端：   
一个产生受保护资源请求的应用，该应用代表resource owner，并且已经获得其
授权。所以其实客户就是指前面说道的这种特性的应用，是种application。
 
authorization server授权服务器：   
在成功验证资源所有者和获得授权后，服务器发行访问令牌给客户端。
 
授权服务器和资源服务器之间的相互作用超出本规范的范围。 授权服务器可能是同一台服务器作为资源的服务器或一个独立的实体。单一授权服务器发出访问令牌可能被多个资源服务器接受。
 
1.2         协议流
 
+------------+                               +-----------------------+
|        |--(A)-Authorization Request ->      |   Resource    |
|        |                               |     Owner    |
|       |<-(B)-- Authorization Grant ---      |                |
|        |                               +-------------------------+
|        |
|        |                               +--------------------------+
|       |--(C)-----    Authorization Grant-->  | Authorization    |
| Client   |                               |     Server     |
|       |<-(D)----- Access Token -------        |                |
|        |                               +------------------------+
|        |
|        |                               +------------------------+
|       |--(E)----- Access Token ------>        |   Resource     |
|        |                               |     Server     |
|       |<-(F)--- Protected Resource ---      |                |
 
图1：抽象的协议流量
 
 
 
如图1所示的抽象流描述的四种角色之间的互动还包括了一下步骤:
(A)client（就是application）向resource owner请求授权。可以直接向resource owner请求，但更好的是通过authorization server作为中间物间接获得。（比如新浪微博的是否允许授权的页面）
(B)client获得了resource owner的授权认可（authorization grant），此授权认可是四种标准授权认可类型中的一种，也可以是其中一种的扩展类型。获得的授权认可的类型由client请求授权所使用的函数和authorization server支持的类型决定。（比如采用特定的请求授权的url，但是传入不同的参数，或者使用的method不同，当然一切都至少服务器要支持）
(C)client提供授权认可，以请求一个access token，该token是可以被authorization server验证的。
(D)authorization server验证client，并且核实授权认可，如果是有效，就发放access token。注意这里是两个验证，1验证client是不是被承认的，2验证resource owner是不是真的授权了。
(E) clent提供access token给resource server验证，判断此client是否可以获取受保护的资源。
(F) resource server核实access token，如果有效则响应请求
 
1.3 权限授予（AuthorizationGrant）
权限授予是一个凭证，代表着资源所有者的授权（访问它的受保护资源），它被客户端用来获得一个访问令牌。此规范定义了四种授予类型：
的授权金是代表资源的凭据由所有者的授权（访问受保护的资源）客户端获得一个访问令牌。 此规范定义了四种授予类型：授权码，隐式，资源所有者密码凭据，客户端凭据，以及一个扩展定义其他类型的机制。
1.3.1  授权码
授权码是通过使用授权服务器作为客户端和资源所有者之间的中介被获取的。客户端请求授权指示资源所有者的授权服务器，这样服务器反过来又指导资源所有者将授权码返回客户端。而不是直接向资源的所有者申请授权。
在引导资源所有者将授权码返回客户端之前，授权服务器验证资源的所有者并获得授权。由于资源的所有者只跟授权服务器认证，资源所有者的凭证不会与客户端分享。
授权码提供了一些重要的安全优势如验证客户端的能力，和不通过资源所有者的用户代理而直接给客户端的访问令牌传输，可能暴露给他人，包括资源的所有者。
1.3.2  隐式
隐式授予是一个简化的授权码流，为了优化客户端实现在浏览器中使用例如JAVAScript的脚本语言。在隐流中，客户端直接发出一个访问令牌（作为资源的所有者授权的结果），而不是给客户端发出一个授权码。授予类型是隐式的就像没有中间的凭据（如授权码）被发出（后来被用来获得一个访问令牌）。
    当发出一个隐含的授予，授权服务器不验证客户端。在某些情况下，可以通过用来给客户端提供的访问令牌的重定向URI，来验证客户端的身份。访问令牌可能会被暴露给资源的所有者或者其它要访问资源所有者的用户代理的应用程序。
隐式授权提高了某些客户端的响应速度和效率​​（如实现在浏览器应用程序的客户端），因为它降低了获得所需的往返访问令牌的数量。然而，这种便利应权衡使用隐式授权的安全隐患，尤其是当授权码授予类型是可用的。
1.3.3  资源所有者密码凭据
资源所有者密码凭据（即用户名和密码）可直接作为一个权限授予获得访问令牌。凭证只有在资源所有者和客户端之间存在一个高等级的信任的时候使用（如设备的操作系统或一个高特权的应用程序），或者当其它权限授予类型不可用时（如授权码）凭据才被使用。
尽管这种授权类型需要引导客户端访问资源所有者凭证，资源所有者凭证被用于一个单一的请求，并交换一个访问令牌。这种授予类型用持久的访问令牌或刷新令牌来交换凭据，这样可以消除客户端必须存储以供将来使用的资源所有者凭证的需要。
1.3.4   ClientCredentials
 客户凭证（或其他形式的客户端身份验证）可被用作一个权限授予当授权范围被限制在保护资源在客户端控制下，或者 授权资源先前被安排给授权服务器。当客户端正以自己的名义行事（客户端也是资源所有者），或者客户端正在请求访问根据一个授权先前安排的授权服务器的受保护资源时，客户端凭证被典型被用来作为一种权限授予。
 1.4 访问令牌
访问令牌是用于访问受保护的资源的凭据。 一个访问令牌是一个字符串，代表发送给客户端的授权。字符串通常是对客户端不透明的。令牌代表访问的具体范围和持续时间，由资源所有者授予，被资源的服务器和授权执行服务器强行执行。
令牌可以表示用于检索授权信息的标识符，或用一种可核查的方式自我包含在授权信息中（即一个令牌字符串的一些数据组成和签名）。 超过了本规范范围的额外的身份验证凭据，可能为了客户端使用令牌而被需要。
访问令牌提供了一个抽象层，用一个简单的被资源服务器理解的令牌来更换不同单一授权结构（如用户名和密码）。 这种抽象使发出的访问令牌比用来接收他们的权限授予更具有限制性，以及删除资源服务器的需要去了解一个广泛的验证方法。
访问令牌可以有不同的格式，结构和基于资源服务安全性需求的方法利用率（如加密属性）。访问令牌的属性和用于访问受保护资源的方法超出了本规范和同伴规范定义的范围。
1.5  刷新令牌
刷新令牌是用来获取访问令牌的凭据。在当前的访问令牌变成无效或过期，或获得额外的访问令牌具有相同或更窄的范围（访问令牌可能有较短期少于资源授权的权限所有者）时，刷新令牌被授权服务器发送给客户端用于获取一个新的访问令牌。分发刷新标记是可选的。如果authorization server分发可刷新令牌，那么当分发access token的时候就会将可刷新令牌包括进去。
刷新令牌是一个字符串，代表权限被资源所有者授予给客户端。字符串通常对客户端是透明的。令牌表示用于检索授权信息的标示符。与访问令牌不同的是，可刷新令牌只被用于授权服务器，而不会发送给资源服务器。发送给资源服务器的始终是访问令牌。
下面看一个关于可刷新令牌的处理流程图。
+--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+
Figure 2 : Refreshing anExpired Access Token
该流程图包括以下步骤：
（A）             客户端访问授权服务器进行验证，通过提供授权认可，以请求访问令牌。
（B）             授权服务器验证客户端并且验证授权认可（四种类型中的一种），如果有效则分发一个访问令牌和一个可刷新令牌
（C）             通过提供访问令牌，客户端可向资源服务器请求受保护资源。
（D）             资源服务器验证验证访问令牌，如果有效，就响应请求。
（E）              步骤（C）和（D）重复进行，直到访问令牌过期。如果client知道访问令牌过期，就直接跳到步骤（G），否则它还会请求受保护资源。
（F）              由于访问令牌失效，资源服务器返回无效令牌错误。
（G）             client请求一个新的访问令牌，通过向授权服务器提供可刷新令牌并进行验证。对client的验证条件是基于client的类型和authorization server的策略。
（H）             authorization server验证client和可刷新令牌，如果有效就分发一个新的访问令牌（你也可以再发送一个新的可刷新令牌）