amp 通過 rfc bsp nbsp ken server 服務 optional

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:

OAuth2 RFC 6749 規範提供的四種基本認證方案