OAuth 2.0是一个非常丰富的授权框架，目前市场上有多种实现

每天‬分享‬最新‬软件‬开发‬，Devops，敏捷‬，测试‬以及‬项目‬管理‬最新‬，最热门‬的‬文章‬，每天‬花‬3分钟‬学习‬何乐而不为‬，希望‬大家‬点赞‬，加‬关注‬，你的‬支持‬是我‬最大‬的‬动力‬。

在传统的客户机-服务器身份验证模型中，资源所有者与客户机共享其凭据，以便客户机可以在必要时访问其资源。客户机通过将资源所有者的凭据传递给资源服务器来完成这项工作，资源服务器在提供对受保护资源的访问之前也会验证相同的凭据。很简单，对吧？

好吧，这个模型有很多相关的问题，下面列出了其中的一些:

• 客户端需要存储资源所有者的凭据以供将来使用
• 如果资源所有者有多个客户端，则需要将相同的凭据分发给所有客户端
• 资源所有者不能轻易撤销对一个客户端的访问，因为它将要求其所有客户端使用资源所有者的新凭据更新其 DB
• 如果一个客户机的 DB 受到损害(因此，资源所有者的凭据也会受到损害) ，那么它会影响所有的客户机
• 没有简单的方法可以将客户机限制在资源所有者的一部分资源上，从而使它们具有过于宽泛的访问权限

OAuth 2.0框架通过引入一个授权层解决了这些问题，这个授权层消除了客户端与资源所有者拥有相同凭证的需要，而是允许客户端使用访问令牌访问资源所有者的资源。

例如，最终用户(资源所有者)可以授予文档打印服务(客户端)对存储在文档服务器(资源服务器)中的文档(资源)的访问权，而无需与文档打印服务共享其凭据。最终用户可以通过与文档打印服务信任的另一方(授权服务器)确认客户端的文档访问请求来批准客户端的文档访问请求，而不是共享它们的凭据。作为回报，授权服务器与文档打印服务共享访问令牌，以访问文档服务器中最终用户的文档。

OAuth 角色

1. Resource Owner - 拥有资源的实体。它能够授予获取资源的权利
2. Resource Server - 承载受保护资源的实体。它能够拒绝或允许访问资源所有者的受保护资源
3. Client 客户 - 寻求获取(并作用于)受保护资源的实体
4. Authorization Server - 协调身份验证和授权的实体

协议流程

     +--------+                                +---------------+
     |        |--(A)--I Need document access-> |   End         |
     |        |                                |   User        |
     |        |<-(B)-Ok, Granted you access--- |               |
     |        |                                +---------------+
     |        |
     |        |                                +---------------+
     |Document|--(C)Yay, I got a grant!------->| Authorization |
     |printing|                                |     Server    |
     |service |<-(D)-Cool, here's your Token --|               |
     |        |                                +---------------+
     |        |
     |        |                                +---------------+
     |        |--(E)Hey, check out this token->|    Document   |
     |        |                                |     Server    |
     |        |<-(F)Cool, here's the document -|               |
     +--------+                                +---------------+

1. 客户端请求资源所有者授予对各种资源的访问权限。客户机要么直接向资源所有者请求授权(如上所示) ，要么使用授权服务器作为中介(建议参见下文)
2. 资源所有者通过返回名为 authorization grant 授权书. 资源可以选择使用四种不同的授权授权类型之一或扩展授权类型进行响应
3. 此授权然后用于请求授权服务器的访问令牌。
4. 授权服务器验证授权，如果有效，则使用访问令牌(还可以选择使用刷新令牌)进行响应
5. 客户端使用此访问令牌向资源服务器请求资源
6. 资源服务器验证令牌，如果有效，则为请求提供服务

授权书

这是一个凭证，表示资源所有者授权客户端访问其受保护的资源。如前所述，它与授权服务器共享，以交换访问令牌。授权补助金有四种类型:

授权码

     +----------+
     | End      |
     | User     |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |  End    -+----(A)-- & Redirection URI ---->|               |
     |  user's  |                                 | Authorization |
     |  User-  -+----(B)-- User authenticates --->|     Server    |
     |  gent    |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |Document |          & Redirection URI                  |
     |Printing |                                             |
     |Service  |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

授权服务器是客户端和资源所有者之间的中介。资源所有者不是直接从资源所有者那里寻求授权，而是被重定向到授权服务器，在授权服务器上对资源所有者进行身份验证。一旦成功地进行了身份验证，资源所有者将连同授权代码一起重定向到客户端。

这种赠款类型有一些优点。

1. 资源所有者的凭据从不与客户端共享，因为资源所有者由授权服务器进行身份验证
2. 访问令牌直接传输到客户端，而不需要通过任何一方(包括资源所有者)

含蓄

     +----------+
     | End      |
     | User     |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |  End    -+----(A)-- & Redirection URI --->|               |
     |  user's  |                                | Authorization |
     |  User-  -|----(B)-- User authenticates -->|     Server    |
     |  Agent   |                                |               |
     |          |<---(C)--- Access Token -------<|               |
     |          |                                +---------------+
     |          |  
     |          |                               
     |          |
     |          |       
     |          |                               
     |     (F)  |
     |          |                                
     +-|--------+
       |    |
      (A)  (D) Access Token
       |    |
       ^    v
     +---------+
     | Document|
     | Printing|
     | Service |
     +---------+

在这种授权类型中，没有像授权代码那样的中间凭据。这意味着，一旦授权服务器对资源所有者进行了身份验证，就会立即向客户机提供一个访问令牌。这肯定比授权代码授予类型快，但具有安全隐患(比如访问令牌可能暴露给资源所有者或其他具有访问资源所有者用户代理权限的应用程序)。当授权授权类型可用时，不建议使用此授权类型。

资源所有者密码凭据

     +----------+
     | End      |
     | User     |
     |          |
     +----------+
          v
          |    End User's
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- End User's ----------->|               |
     | Document|         Password Credentials     | Authorization |
     | Printing|                                  |     Server    |
     | Service |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

在此授予类型中，客户端使用资源所有者的凭据来获取第一次使用的访问令牌。一旦访问令牌可用于后续的资源请求，就会使用访问令牌。这消除了在客户端存储资源所有者凭据的需要。这在资源所有者与客户端具有可信关系的情况下非常有用。当授权授权类型可用时，不建议使用此授权类型。

客户资格证明

     +----------+                                  +---------------+
     |          |                                  |               |
     |          |>--(A)- Client Authentication --->| Authorization |
     |End User's|                                  |     Server    |
     |   app    |<--(B)---- Access Token ---------<|               |
     |          |                                  |               |
     +----------+                                  +---------------+

此授予类型用于客户端控制资源或客户端也是资源所有者的情况。在这种情况下，客户端凭据(预先与授权服务器共享)用作授权许可，以获得访问令牌。

还有一个扩展授权类型，这是一种创建更多授权类型的扩展机制。这超出了本文的范围。

访问令牌

访问令牌是用于访问资源服务器承载的资源所有者的受保护资源的凭据。它是一个简单的字符串，自包含安全且可验证的关键授权信息。这还包含所请求资源的作用域和访问时间，资源服务器和/或授权服务器可以执行这些作用域和访问时间。通常对这些令牌进行签名，这也有助于资源服务器验证客户端的标识。

对于每个资源请求，访问令牌连同其他请求属性一起发送到资源服务器。这个令牌的结构是特定于实现的，不受 OAuth 2.0规范的约束。有关访问令牌格式的示例，请阅读本文。

刷新令牌

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  |Document|                            |  Server  |   |     Server    |
  |Printing|--(E)---- Access Token ---->|          |   |               |
  |Resource|                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

这是客户端在当前访问令牌过期或无效时用于从授权服务器获取访问令牌的另一个凭据。这取决于授权服务器是否发出刷新令牌。

OAuth 2.0是一个非常丰富的授权框架，目前市场上有多种实现。它已被证明是安全的，并经受住了时间的考验，这从最近许多组织采用它就可以明显看出。在以后的教程中，我们将通过一些工作示例更深入地研究这个框架。