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:瀏覽器