微服務架構統一安全認證設計與實踐

當企業應用系統逐漸增多後，每個系統單獨管理各自的用戶數據容易形成信息孤島，分散的用戶管理模式阻礙了企業應用向平臺化演進。當企業的互聯網業務發展到一定規模，構建統一的標準化賬戶管理體系將是必不可少的，因爲它是企業互聯網雲平臺的重要基礎設施，能夠爲平臺帶來統一的帳號管理、身份認證、用戶授權等基礎能力，爲企業帶來諸如跨系統單點登錄、第三方授權登錄等基礎能力，爲構建開放平臺和業務生態提供了必要條件。

名詞定義

• Third-party application：第三方應用程序，本文中又稱 “客戶端”（client）。

• HTTP service：HTTP 服務提供商，本文中簡稱 “服務提供商”。

• Resource Owner：資源所有者，本文中又稱 “用戶”（user），即登錄用戶。

• User Agent：用戶代理，本文中就是指瀏覽器。

• Authorization server：認證服務器，即服務提供商專門用來處理認證的服務器。

• Resource server：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，可以是同一臺服務器，也可以是不同的服務器。

研發背景

單體應用體系下，應用是一個整體，一般針對所有的請求都會進行權限校驗。請求一般會通過一個權限的攔截器進行權限的校驗，在登錄時將用戶信息緩存到 session 中，後續訪問則從緩存中獲取用戶信息。

隨着 Restful API、微服務的興起，基於 Token 的認證現在已經越來越普遍。Token 和 Session ID 不同，並非只是一個 key。Token 一般會包含用戶的相關信息，通過驗證 Token 就可以完成身份校驗。

基於 Token 認證的優勢如下：

• 服務端無狀態：Token 機制在服務端不需要存儲 session 信息，因爲 Token 自身包含了所有用戶的相關信息。

• 性能較好，因爲在驗證 Token 時不用再去訪問數據庫或者遠程服務進行權限校驗，自然可以提升不少性能。

• 支持移動設備，支持跨程序調用，Cookie 是不允許垮域訪問的，而 Token 則不存在這個問題。

研發目標

通過標準安全認證流程，異構系統或跨服務間能夠靈活地實現指定功能部件或服務的集成、統一的安全認證。

基於 Token 認證的一個典型流程如下：

1. 用戶輸入登錄信息（或者調用 Token 接口，傳入用戶信息），發送到身份認證服務進行認證（身份認證服務可以和服務端在一起，也可以分離，看微服務拆分情況了）。

2. 身份驗證服務驗證登錄信息是否正確，返回接口（一般接口中會包含用戶基礎信息、權限範圍、有效時間等信息），客戶端存儲接口，可以存儲在 Session 或者數據庫中。

3. 客戶端將 Token 放在 HTTP 請求頭中，發起相關 API 調用。

4. 被調用的微服務，驗證 Token 權限。

5. 服務端返回相關資源和數據。

安全認證功能點：

1. 獲取憑證，第三方應用客戶端使用客戶端編碼 / 安全碼、資源所有者用戶名 / 密碼等證件信息從授權服務器上獲取 Access Token 資源訪問憑證。

2. 登錄授權，客戶端攜帶 Access Token 憑證訪問服務器資源，資源服務器驗證 Token、第三方應用憑證信息、資源所有者 User 合法性，通過 Token 讀取資源所有者身份信息（user）加載資源所有者的權限項執行登錄。

3. 訪問鑑權，第三方應用客戶端訪問服務端資源，系統驗證訪問者 Access Token 合法性、權限信息，驗證憑證（Access Token）正確，此時資源服務器就會返回資源信息。

4. 憑證續約，Access token 訪問憑證過期需要進行憑證續約，刷新 Token 憑證有效期。

技術選型分析

• 系統授權採用 OAuth2 開放式授權標準密碼模式。

• Token 採用 JWT 標準。

OAuth 開放授權

OAuth（Open Authorization，開放授權）是爲用戶資源的授權定義了一個安全、開放及簡單的標準，第三方無需知道用戶的賬號及密碼，就可獲取到用戶的授權信息。

主要的四種授權方式：

• 授權碼模式（authorization code）用在客戶端與服務端應用之間授權碼。

• 簡化模式（implicit）用在移動 app 或者 web app（這些 app 是在用戶的設備上的，如在手機上調起微信來進行認證授權）。不通過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了 “授權碼” 這個步驟，因此得名。所有步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不需要認證。

• 密碼模式（resource owner password credentials）應用直接都是受信任的（都是由一家公司開發的）密碼模式中，用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息，向 “服務商提供商” 索要授權。在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。

• 客戶端模式（client credentials）用在應用 API 訪問客戶端模式（Client Credentials Grant）指客戶端以自己的名義，而不是以用戶的名義，向 “服務提供商” 進行認證。嚴格地說，客戶端模式並不屬於 OAuth 框架所要解決的問題。在這種模式中，用戶直接向客戶端註冊，客戶端以自己的名義要求 “服務提供商” 提供服務，其實不存在授權問題。

Json Web Token（JWT）

Json Web Token（JWT），是爲了在網絡應用環境間傳遞聲明而執行的一種基於 JSON 的開放標準（RFC 7519）。該 Token 被設計爲緊湊且安全的，特別適用於分佈式站點的單點登錄（SSO）場景。JWT 的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該 Token 也可直接被用於認證，也可被加密。

認證流程邏輯

系統授權

第三方應用客戶端使用客戶端編碼 / 安全碼、資源所有者用戶名 / 密碼等證件信息從授權服務器上獲取 Access Token 資源訪問憑證。

系統授權頒發給客戶應用 Access Token。

系統鑑權

客戶端攜帶 Access Token 憑證訪問服務器資源，資源服務器驗證 Token、第三方應用、資源所有者 User 合法性，通過 Token 讀取資源所有者身份信息（user）加載資源所有者的權限執行登錄。

系統驗證訪問者 Access Token 合法性、權限信息，驗證憑證（Access Token）正確，此時資源服務器就會返回資源信息。

憑證續約

Access Token 訪問憑證過期需要進行憑證續約，刷新 Token 憑證有效期。

接口設計

授權憑證

獲取授權憑證，校驗客戶端身份信息、校驗資源所有者身份信息，下發 Token 憑證。

客戶端編碼 / 安全碼需要第三方應用到系統註冊審覈通過後生成。

授權憑證續約

獲取續約授權憑證，校驗客戶端身份信息、校驗 RefreshToken 憑證，下發 Token 憑證。

作者：mars

來源：https://juejin.cn/post/6906149001520037902

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/gX4NUOCK48ojnlo2xkSelw