OAuth2 RFC 6749 规范提供的四种基本认证方案

  OAuth2 RFC 6749 规范提供了四种基本认证方案，如下针对这四种认证方案以及它们在本实现中的使用方式进行分别说面。

第一种认证方式： Authorization Code Grant (受权码认证）

    受权码经过使用受权服务器作为客户端与资源全部者的中介而得到。客户端不是直接从资源全部者请求受权，而是引导资源全部者至受权服务器（由在RFC2616中定义的用户代理），受权服务器以后引导资源全部者带着受权码回到客户端。

    在引导资源全部者携带受权码返回客户端前，受权服务器会鉴定资源全部者身份并得到其受权。因为资源全部者只与受权服务器进行身份验证，因此资源全部者的凭据不须要与客户端分享。

    受权码提供了一些重要的安全益处，例如验证客户端身份的能力，以及向客户端直接的访问令牌的传输而非经过资源全部者的用户代理来传送它而潜在暴露给他人（包括资源全部者）。

    受权码许可类型用于得到访问令牌和刷新令牌并未机密客户端进行了优化。因为这是一个基于重定向的流程，客户端必须可以与资源全部者的用户代理（一般是Web浏览器）进行交互并可以接收来自受权服务器的传入请求（经过重定向）。

  Authorization Code Grant 过程（又称为 Web Server Flow) 参见以下：
     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |          +----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent   +----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |          +----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

    注：说明步骤（A）、（B）和（C）的直线由于经过用户代理而被分为两部分。
    图1：受权码流程

    在图1中所示的流程包括如下步骤：

    （A）客户端经过向受权端点引导资源全部者的用户代理开始流程。客户端包括它的客户端标识、请求范围、本地状态和重定向URI，一旦访问被许可（或拒绝）受权服务器将传送用户代理回到该URI。
    （B）受权服务器验证资源拥有者的身份（经过用户代理），并肯定资源全部者是否授予或拒绝客户端的访问请求。
    （C）假设资源全部者许可访问，受权服务器使用以前（在请求时或客户端注册时）提供的重定向URI重定向用户代理回到客户端。重定向URI包括受权码和以前客户端提供的任何本地状态。
    （D）客户端经过包含上一步中收到的受权码从受权服务器的令牌端点请求访问令牌。当发起请求时，客户端与受权服务器进行身份验证。客户端包含用于得到受权码的重定向URI来用于验证。
    （E）受权服务器对客户端进行身份验证，验证受权代码，并确保接收的重定向URI与在步骤（C）中用于重定向客户端的URI相匹配。若是经过，受权服务器响应返回访问令牌与可选的刷新令牌。

    过程实现：
    1.    client app 使用 app id 获取 authorization code: