分佈式認證方案

隨着軟件環境和需求的變化，軟件的架構由單體結構演變爲分佈式架構，具有分佈式架構的系統叫分佈式系統，分布式系統的運行通常依賴網絡，它將單體結構的系統分爲若干服務，服務之間通過網絡交互來完成用戶的業務處理，當前流行的微服務架構就是分佈式系統架構，如下圖:

分佈式系統具體如下基本特點:

分佈式系統的每個服務都會有認證、授權的需求，如果每個服務都實現一套認證授權邏輯會非常冗餘，考慮分佈式系統共享性的特點，需要由獨立的認證服務處理系統認證授權的請求;考慮分佈式系統開放性的特點，不僅對系統內部服務提供認證，對第三方系統也要提供認證。分佈式認證的需求總結如下:

統一認證授權
提供獨立的認證服務，統一處理認證授權。無論是不同類型的用戶，還是不同種類的客戶端(web端，H5、APP)，均採用一致的認證、權限、會話機制，實現統一認證授權。

要實現統一則認證方式必須可擴展，支持各種認證需求，比如:用戶名密碼認證、短信驗證碼、二維碼、人臉識別等認證方式，並可以非常靈活的切換。
應用接入認證
應提供擴展和開放能力，提供安全的系統對接機制，並可開放部分API給接入第三方使用，一方應用(內部系統服務)和三方應用(第三方應用)均採用統一機制接入。

基於session的認證方式

在分佈式的環境下，基於session的認證會出現一個問題，每個應用服務都需要在session中存儲用戶身份信息，通過負載均衡將本地的請求分配到另一個應用服務需要將session信息帶過去，否則會重新認證。

這個時候，通常的做法有下面幾種:
- Session複製: 多臺應用服務器之間同步session，使session保持一致，對外透明。
- Session黏貼: 當用戶訪問集羣中某臺服務器後，強制指定後續所有請求均落到此機器上。
- Session集中存儲: 將Session存入分佈式緩存中，所有服務器應用實例統一從分佈式緩存中存取Session。
總體來講，基於session認證的認證方式，可以更好的在服務端對會話進行控制，且安全性較高。但是，session機制方式基於cookie，在複雜多樣的移動客戶端上不能有效的使用，並且無法跨域，另外隨着系統的擴展需提高 session的複製、黏貼及存儲的容錯性。
基於token的認證方式

基於token的認證方式，服務端不用存儲認證數據，易維護擴展性強，客戶端可以把token 存在任意地方，並且可以實現web和app統一認證機制。其缺點也很明顯，token由於自包含信息，因此一般數據量較大，而且每次請求都需要傳遞，因此比較佔帶寬。另外，token的簽名驗籤操作也會給cpu帶來額外的處理負擔。

根據選型的分析，決定採用基於token的認證方式，它的優點是:

分佈式系統認證技術方案見下圖:

流程描述:

用戶通過接入方(應用)登錄，接入方採取OAuth2.0方式在統一認證服務(UAA)中認證。
認證服務(UAA)調用驗證該用戶的身份是否合法，並獲取用戶權限信息。
認證服務(UAA)獲取接入方權限信息，並驗證接入方是否合法。
若登錄用戶以及接入方都合法，認證服務生成jwt令牌返回給接入方，其中jwt中包含了用戶權限及接入方權限。
後續，接入方攜帶jwt令牌對API網關內的微服務資源進行訪問。
API網關對令牌解析、並驗證接入方的權限是否能夠訪問本次請求的微服務。
如果接入方的權限沒問題，API網關將原請求header中附加解析後的明文Token，並將請求轉發至微服務。
微服務收到請求，明文token中包含登錄用戶的身份和權限信息。因此後續微服務自己可以幹兩件事:
- 用戶授權攔截(看當前用戶是否有權訪問該資源)
- 將用戶信息存儲進當前線程上下文(有利於後續業務邏輯隨時獲取當前用戶信息)

流程所涉及到UAA服務、API網關這三個組件職責如下:

統一認證服務(UAA) 它承載了OAuth2.0接入方認證、登入用戶的認證、授權以及生成令牌的職責，完成實際的用戶認證、授權功能。
API網關作爲系統的唯一入口，API網關爲接入方提供定製的API集合，它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存等。API網關方式的核心要點是，所有的接入方和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。