基於OAuth2.0的統一身份認證中心設計

1. 引言

公司經歷多年發展后，在內部存在多套信息系統，每套信息系統的作用各不相同，每套系統也都擁有自己獨立的賬號密碼權限體系，這時，每個人員都需要記住不同系統的賬號密碼，人員入職和離職時，人事部門都需要對多個系統進行賬號的分配和關停，更嚴重的是部分系統的管理權限不在人事部門，人員離職時系統的賬號未能及時關停，存在較大的安全風險。
為此，公司計划建立一個統一的身份認證中心來統一管理賬號密碼，由認證中心來統一發放和回收賬號，其他業務系統通過簡單改造以實現與認證中心進行集成。比較了SAML2.0和OAuth2.0兩種協議方案，最終選擇了相對簡單的OAuth2.0。

2. OAuth2.0

OAuth 2.0官方的介紹是：

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.

OAuth 2.0是用於授權的行業標准協議。OAuth 2.0取代了在2006年創建的原始OAuth協議上所做的工作。OAuth 2.0專注於客戶端開發人員的簡單性，同時為Web應用程序，桌面應用程序，手機和客廳設備提供特定的授權流程。

在目前的系統中，各系統用戶需要訪問系統內的資源時，一般需要憑用戶名和密碼登錄系統后才能訪問，這時各系統自己存儲和管理用戶的用戶名和密碼，就會出現文章之初出現的問題（實際問題可能會有其他情況），而使用OAuth,用戶的賬號密碼存儲在身份認證中心，可以有效避免此類問題的產生。

關於OAuth2.0框架的描述可參見以下鏈接：
OAuth 2.0 Framework - RFC 6749
OAuth 2.0授權框架

2.1 角色

OAuth定義了四種角色：

• 資源所有者
  能夠許可對受保護資源的訪問權限的實體。當資源所有者是個人時，它被稱為最終用戶。
• 資源服務器
  托管受保護資源的服務器，能夠接收和響應使用訪問令牌對受保護資源的請求。
• 客戶端
  使用資源所有者的授權代表資源所有者發起對受保護資源的請求的應用程序。術語“客戶端”並非特指任何特定的的實現特點（例如：應用程序是否是在服務器、台式機或其他設備上執行）。
• 授權服務器
  在成功驗證資源所有者且獲得授權后頒發訪問令牌給客戶端的服務器。

授權服務器和資源服務器之間的交互超出了本規范的范圍。授權服務器可以和資源服務器是同一台服務器，也可以是分離的個體。一個授權服務器可以頒發被多個資源服務器接受的訪問令牌

2.2. 協議流程

圖1中所示的抽象的OAuth 2.0流程描述了四種角色之間的交互，包括以下步驟：

• （A）客戶端從資源所有者處請求授權。授權請求可以直接向資源所有者發起（如圖所示），或者更可取的是通過授權服務器作為中介間接發起。
• （B）客戶端收到授權許可，這是一個代表資源所有者的授權的憑據，使用本規范中定義的四種許可類型之一或者使用擴展許可類型表示。授權許可類型取決於客戶端請求授權所使用的方法以及授權服務器支持的類型。
• （C）客戶端與授權服務器進行身份認證並出示授權許可以請求訪問令牌。
• （D）授權服務器驗證客戶端身份並驗證授權許可，若有效則頒發訪問令牌。
• （E）客戶端從資源服務器請求受保護資源並出示訪問令牌進行身份驗證。
• （F）資源服務器驗證訪問令牌，若有效則處理該請求。

客戶端從資源所有者獲得授權許可（步驟（A）和（B）所示）的更好方法是使用授權服務器作為中介。

2.3 授權許可

授權許可是一個代表資源所有者授權（訪問受保護資源）的憑據，客戶端用它來獲取訪問令牌。本規范定義了四種許可類型——授權碼、隱式許可、資源所有者密碼憑據和客戶端憑據——以及用於定義其他類型的可擴展性機制。
本次我們采用的是常用的授權碼授權方式。

3. 授權碼模式

參考：
What is the OAuth 2.0 Authorization Code Grant Type?
授權碼許可

3.1 授權碼模式流程

在圖中所示的流程包括以下步驟：

• （A）客戶端通過向授權端點引導資源所有者的用戶代理開始流程。客戶端包括它的客戶端標識、請求范圍、本地狀態和重定向URI，一旦訪問被許可（或拒絕）授權服務器將傳送用戶代理回到該URI。
• （B）授權服務器驗證資源擁有者的身份（通過用戶代理），並確定資源所有者是否授予或拒絕客戶端的訪問請求。
• （C）假設資源所有者許可訪問，授權服務器使用之前（在請求時或客戶端注冊時）提供的重定向URI重定向用戶代理回到客戶端。重定向URI包括授權碼和之前客戶端提供的任何本地狀態。
• （D）客戶端通過包含上一步中收到的授權碼從授權服務器的令牌端點請求訪問令牌。當發起請求時，客戶端與授權服務器進行身份驗證。客戶端包含用於獲得授權碼的重定向URI來用於驗證。
• （E）授權服務器對客戶端進行身份驗證，驗證授權代碼，並確保接收的重定向URI與在步驟（C）中用於重定向（資源所有者的用戶代理）到客戶端的URI相匹配。如果通過，授權服務器響應返回訪問令牌與可選的刷新令牌。

3.2 授權請求

客戶端通過按(../AppendixB/b.md)使用“application/x-www-form-urlencoded”格式向授權端點URI的查詢部分添加下列參數構造請求URI：

• response_type
  必需的。值必須被設置為“code”。
• client_id
  必需的。客戶端標識。
• redirect_uri
  可選的。回調的URL地址。
• scope
  可選的。訪問請求的范圍。
• state
  推薦的。客戶度用於維護請求和回調之間的狀態的不透明的值。當重定向用戶代理回到客戶端時，授權服務器包含此值。該參數應該用於防止跨站點請求偽造。

客戶端使用HTTP重定向響應向構造的URI定向資源所有者，或者通過經由用戶代理至該URI的其他可用方法。
例如，客戶端使用TLS定向用戶代理發起下述HTTP請求（額外的換行僅用於顯示目的）：

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
 Host: server.example.com

授權服務器驗證該請求，確保所有需要的參數已提交且有效。如果請求是有效的，授權服務器對資源所有者進行身份驗證並獲得授權決定（通過詢問資源所有者或通過經由其他方式確定批准）。

當確定決定后，授權服務器使用HTTP重定向響應向提供的客戶端重定向URI定向用戶代理，或者通過經由用戶代理至該URI的其他可行方法。

3.3 授權響應

如果資源所有者許可訪問請求，授權服務器頒發授權碼，通過使用“application/x-www-form-urlencoded”格式向重定向URI的查詢部分添加下列參數傳遞授權碼至客戶端：

• code
  必需的。授權服務器生成的授權碼。授權碼必須在頒發后很快過期以減小泄露風險。推薦的最長的授權碼生命周期是10分鍾。客戶端不能使用授權碼超過一次。如果一個授權碼被使用一次以上，授權服務器必須拒絕該請求並應該撤銷（如可能）先前發出的基於該授權碼的所有令牌。授權碼與客戶端標識和重定向URI綁定。
• state
  必需的，若“state”參數在客戶端授權請求中提交。從客戶端接收的精確值。

例如，授權服務器通過發送以下HTTP響應重定向用戶代理：

    HTTP/1.1 302 Found
    Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

客戶端必須忽略無法識別的響應參數。本規范未定義授權碼字符串大小。客戶端應該避免假設代碼值的長度。授權服務器應記錄其發放的任何值的大小。

響應錯誤

3.4 訪問令牌請求

客戶端通過使用按“application/x-www-form-urlencoded”格式在HTTP請求實體正文中發送下列UTF-8字符編碼的參數向令牌端點發起請求：

• grant_type
  必需的。值必須被設置為“authorization_code”。
• code
  從授權服務器收到的授權碼。
• redirect_uri
  必需的，若“redirect_uri”參數包含在授權請求中，且他們的值必須相同。
• client_id
  必需的，如果客戶端沒有與授權服務器進行身份認證。

如果客戶端類型是機密的或客戶端被頒發了客戶端憑據（或選定的其他身份驗證要求），客戶端必須如
必需的，如果客戶端沒有與授權服務器進行身份驗證。

例如，客戶端使用TLS發起如下的HTTP請求（額外的換行符僅用於顯示目的）：

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

授權服務器必須：

• 要求機密客戶端或任何被頒發了客戶端憑據（或有其他身份驗證要求）的客戶端進行客戶端身份驗證，
• 若包括了客戶端身份驗證，驗證客戶端身份，
• 確保授權碼頒發給了通過身份驗證的機密客戶端，或者如果客戶端是公開的，確保代碼頒發給了請求中的“client_id”，
• 驗證授權碼是有效的，並
• 確保給出了“redirect_uri”參數，若“redirect_uri”參數包含在初始授權請求中，且若包含，確保它們的值是相同的。

3.5 訪問令牌響應

如果訪問令牌請求是有效的且被授權，授權服務器如5.1節所述頒發訪問令牌以及可選的刷新令牌。如果請求客戶端身份驗證失敗或無效，授權服務器如5.2節所述的返回錯誤響應。

一個樣例成功響應：

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}