作者：mars

鏈接：https://juejin.cn/post/6906149001520037902

-     前言     -

當企業(yè)應用系統(tǒng)逐漸增多后，每個系統(tǒng)單獨管理各自的用戶數(shù)據(jù)容易形成信息孤島，分散的用戶管理模式阻礙了企業(yè)應用向平臺化演進。

企業(yè)的互聯(lián)網(wǎng)業(yè)務發(fā)展到一定規(guī)模，構建統(tǒng)一的標準化賬戶管理體系將是必不可少的，因為它是企業(yè)互聯(lián)網(wǎng)云平臺的重要基礎設施，能夠為平臺帶來統(tǒng)一的帳號管理、身份認證、用戶授權等基礎能力，為企業(yè)帶來諸如跨系統(tǒng)單點登錄、第三方授權登錄等基礎能力，為構建開放平臺和業(yè)務生態(tài)提供必要條件。

- 名詞定義 -

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

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

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

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

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

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

- 研發(fā)背景 -

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

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

基于 Token 認證的優(yōu)勢如下：

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

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

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

- 研發(fā)目標 -

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

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

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

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

3. 客戶端將 Token 放在 HTTP 請求頭中，發(fā)起相關 API 調(diào)用。

4. 被調(diào)用的微服務，驗證 Token 權限。

5. 服務端返回相關資源和數(shù)據(jù)。

1、安全認證功能點

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

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

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

（4）憑證續(xù)約，Access token訪問憑證過期需要進行憑證續(xù)約，刷新Token憑證有效期。

2、技術選型分析

1. 系統(tǒng)授權采用OAuth2開放式授權標準密碼模式。

2. Token采用JWT標準。

（1）OAuth開放授權

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

主要的四種授權方式：

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

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

• 密碼模式（resource owner password credentials）應用直接都是受信任的(都是由一家公司開發(fā)的)密碼模式中，用戶向客戶端提供自己的用戶名和密碼?？蛻舳耸褂眠@些信息，向"服務商提供商"索要授權。在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。

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

（2）Json web token (JWT)

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

3、認證流程邏輯

（1）系統(tǒng)授權

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

系統(tǒng)授權頒發(fā)給客戶應用Access Token：

（2）系統(tǒng)鑒權

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

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

（3）憑證續(xù)約

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

- 接口設計 -

1. 授權憑證

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

客戶端編碼/安全碼需要第三方應用到系統(tǒng)注冊審核通過后生成。

2. 授權憑證續(xù)約

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