OAuth2.0-draft-ietf-oauth-v2-22中的关键性概念解释

一、角色                                                                                                                              

OAuth定义了四种角色：

1、resource owner资源所有者

可以获得授权去访问受保护的资源的实体。这句很绕口，简单来说就是资源的所有者，这个所有者是指当初上传或生成的那个所有者，并不是指服务器的所有者。

2、resource server资源服务器

承载受保护资源的服务器，可以接收和响应使用access token（访问令牌）请求受保护资源。

3、client客户

一个产生受保护资源请求的应用，该应用代表resource owner，并且已经获得其授权。所以其实客户就是指前面说道的这种特性的应用，是种application。

4、authorization server授权服务器

用来分发access token的服务器，他的分发对象是client，反过来说，就是client会向authorization server请求access token。当client获得access token后，才能说已经验证了resource owner，并且已经获得其授权。

二、协议流                                                                                                                             

接下来让我们看一张图，来更好的理解四种角色间的交互作用

     +--------+                               +---------------+
     |        |--(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 ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow

上图代表了整个协议流程的抽象图。它展示了整个流程，以及四个角色的作用，接下来我逐条解释

（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，如果有效则响应请求。

三、Authorization Grant授权认可                                                                                                           

授权认可是一种凭证，代表resource owner已授权于你（client）可以访问其受保护的资源。授权认可被用于获取access token。这里有四种基本的认可类型：

→授权码（authorization code）

→隐式（implicit）

→用户密码（resource owner password credentials）

→应用凭证（client credentials）

 你也可以给予以上的四种，自己扩展新的类型。

1、authorization code授权码

当使用authorization server作为client和resource owne之间的中间物时，会用到授权码。用来代替直接向resource owner直接请求授权，client会将resource owner指向一台authorization server，在authorization server所提供的页面上，完成相应操作后，authorization server会将resource owner指引回client，并且返回的还有authorization code。

在指引resource owner返回client并带有authorization code之前，authorization server会验证resource owner并获得授权（注意这里获得授权的是authorization server）。因为resource owner只是向authorization server进行授权，所以resource owner的凭证式不会共享给client的。

authorization code提供了一些重要的安全信息，比如授权给client的行为，access token的传输。

这里的access token传输是指，直接传给client，而无不通过resource owner的user-agent（比如浏览器）暴露给他人，包括resource owner本人。简单说来就是直接给client，不会再给resource owner，access token。

场景：

接下来，我们模拟一个应用场景。现在你的应用，需要整合新浪微博API，现在假设已经整合完成了。对于用户来说他的使用时如下流程，

点击使用新浪微博账号登陆-》跳转到新浪微博的一个验证页面（authorization server）-》登陆完成后直接返回应用的页面并传给client相应的authorization code-》client可以根据此authorization code获得access token。

2、Implicit隐式

隐式授权是一个简化了的authorization code处理流程，该流程是为应用（client）能在浏览器中使用脚本语言（比如JavaScript）实现类似authorization code处理流程而特地优化的。在隐式处理流程中，authorization server不会向client发放authorization code，而是直接发放access token（以此作为resource owner授权的结果）。此类型的授权是隐性的，不会分发中间物凭证（eg.authorization code），并且会用于获取access token。

当分发一个隐式授权时，authorization server不会验证client。在某些情况，client身份可以通过跳转URI去验证，该跳转URI是用于向client传递access token。获得的access token会暴露给resource owner或其他可以访问resource owner的User-agent的应用。

隐式授权改进了响应性和一些client的效率（比如client是一个浏览器应用），这是由于其减少了为获得access token而进行的交互次数。但也会带来安全性上的问题，所以可以使用authorization code的时候，是使用哪种要好好权衡。

3、Resource Owner Password Credentials用户密码凭证

用户密码凭证（比如用户名和密码）可以直接使用，作为一种授权类型去获得access token。只有在高度信任resource owner和client的时候，才应该采用凭证。（比如，设备操作系统或高特权应用），还有当其他授权认可类型（比如authorization code）不可用时才使用。

尽管此类授权类型会指引client访问resource owner凭证，但resource owner凭证被用于一次请求并且用于交换access token。此授权类型可以消除因client希望以后使用而去保存resource owner凭证的需求，这是因为通过使用一个长期有效的access token（或者刷新access token）就可以去交换凭证 。

4、Client Credentials应用凭证

当授权范围限制在client控制下的受保护资源或是先前使用authorization server处理过的受保护资源时，client credentials应用凭证（或其他形式的client验证）可以用作授权认证。应用凭证用作认证授权的典型情况是，当client代表自己的时候（即，client就是resource owner），或请求访问基于（先前由authorization server处理过的）授权的受保护资源。

四、Access Token访问令牌                                                                                                       

access token是一种用于获取受保护资源的凭证，它是一条字符串，该字符串代表authorization server分发给client的授权。对于client来说此字符串是透明的。访问令牌根据resource owner的指示，指定了client访问的范围和时效，并可以被resource server和authorization server使用（也可以认为是需要用到，帮助验证）。

令牌将作为一个标示符，用作获取授权信息，或自己就以某种惯例或形式包含授权信息（比如，令牌字符串由一些数据和一个签名组成）。

访问令牌提供了一个抽象层，通过使用resource server可以理解的单个token去代替不同的授权结构（比如，用户名和密码）。此抽象使得分发访问令牌比用于获得令牌的授权认可有更大的限制，同时也不需要resource server理解不同的验证方法。

根据resource server安全需要，访问令牌可以有不同的格式，结构，和工具方法（比如加密属性）。

五、Refresh Token可刷新令牌

可刷新令牌是用于获得访问令牌的凭证。可刷新令牌是由authorization server分发的，当前访问令牌失效时，可刷新令牌可以用于获得一个新的访问令牌或得到一个相同使用范围（或更小）的附加访问令牌。（访问令牌可能比resource owner的授权，有更少的生存时间和权限，可以认为是小于等于关系）。分发可刷新令牌是可选的，如果authorization server分发可刷新令牌，那么当分发access token的时候就会将可刷新令牌包括进去。

可刷新令牌是一个字符串，代表resource owner对client的授权。该字符串对client是透明的。令牌代表一个标示符，用于接收授权信息。与访问令牌不同的是，可刷新令牌只被用于authorization server，而不会发送给resource server。发送给resource 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 an Expired Access Token

该流程图包括以下步骤：

（A）：client访问authorization server进行验证，通过提供提供授权认可，以请求access token。

（B）：authorization server验证client，并且验证授权认可（四种类型中的一种），如果有效则分发一个访问令牌和一个可刷新令牌

（C）：通过提供access token，client可向resource server请求受保护资源

（D）：resource server验证访问令牌，如果有效，就响应请求

（E）: 步骤（C）和（D）重复进行，直到访问令牌过期。如果client知道访问令牌过期，就直接跳到步骤（G），否则它还会请求受保护资源。

（F）：由于访问令牌失效，resource server返回无效令牌错误。

（G）：client请求一个新的访问令牌，通过向authorization server提供可刷新令牌并进行验证。对client的验证条件是基于client的类型和authorization server的策略。

（H）：authorization server验证client和可刷新令牌，如果有效就分发一个新的访问令牌（你也可以再发送一个新的可刷新令牌）