文章目錄
2.分佈式系統的特點
- 分佈性：每個部分都可以獨立部署，服務之間交互通過網絡進行通信，比如：訂單服務、商品服務
- 伸縮性：每個部分都可以集羣方式部署，並可針對部分結點進行硬件及軟件擴容，具有一定的伸縮能力
- 共享性：每個部分都可以作爲共享資源對外提供服務，多個部分可能有操作共享資源的情況。
- 開放性：每個部分根據需求都可以對外發布共享資源的訪問接口，並可允許第三方系統訪問。
2.分佈式認證需求
分佈式系統的每個服務都會有認證、授權的需求，如果每個服務都實現一套認證授權邏輯會非常冗餘，考慮分佈式系統共享性的特點，需要由獨立的認證服務處理系統認證授權的請求；考慮分佈式系統開放性的特點，不僅對系統內部服務提供認證，對第三方系統也要提供認證。分佈式認證的需求總結如下：
①統一認證授權
提供獨立的認證服務，統一處理認證授權。
無論是不同類型的用戶，還是不同種類的客戶端(web端，H5、APP)，均採用一致的認證、權限、會話機制，實現統一認證授權。要實現統一則認證方式必須可擴展，支持各種認證需求，比如：用戶名密碼認證、短信驗證碼、二維碼、人臉識別 等認證方式，並可以非常靈活的切換。
②應用接入認證
應提供擴展和開放能力，提供安全的系統對接機制，並可開放部分API給接入第三方使用，一方應用（內部系統服務）和三方應用（第三方應用）均採用統一機制接入。
3.分佈式認證方案
①基於session的認證方式
在分佈式的環境下，基於session的認證會出現一個問題，每個應用服務都需要在session中存儲用戶身份信息，通 過負載均衡將本地的請求分配到另一個應用服務需要將session信息帶過去，否則會重新認證。
這個時候，通常的做法有下面幾種：
- Session複製：多臺應用服務器之間同步
session，使session保持一致，對外透明。 - Session黏貼：當用戶訪問集羣中某臺服務器後，強制指定後續所有請求均落到此機器上。
- Session集中存儲：將
Session存入分佈式緩存中，所有服務器應用實例統一從分佈式緩存中存取Session
②基於token的認證方式
基於token的認證方式，服務端不用存儲認證數據，易維護擴展性強， 客戶端可以把token存在任意地方，並且可 以實現web和app統一認證機制。其缺點也很明顯，token由於自包含信息，因此一般數據量較大，而且每次請求 都需要傳遞，因此比較佔帶寬。另外，token的簽名驗籤操作也會給cpu帶來額外的處理負擔。
③選用方案
根據選型的分析，決定採用基於token的認證方式，它的優點是：
1、適合統一認證的機制，客戶端、一方應用、三方應用都遵循一致的認證機制。
2、token認證方式對第三方應用接入更適合，因爲它更開放，可使用當前有流行的開放協議Oauth2.0、JWT等。
3、一般情況服務端無需存儲會話信息，減輕了服務端的壓力。
4.分佈式認證流程
- 用戶通過接入方（應用）登錄，接入方採取
OAuth2.0方式在統一認證服務(UAA)中認證。 - 認證服務(
UAA)調用驗證該用戶的身份是否合法，並獲取用戶權限信息。 - 認證服務(
UAA)獲取接入方權限信息，並驗證接入方是否合法。 - 若登錄用戶以及接入方都合法，認證服務生成
jwt令牌返回給接入方，其中jwt中包含了用戶權限及接入方權 限。 - 後續，接入方攜帶
jwt令牌對API網關內的微服務資源進行訪問。 API網關對令牌解析、並驗證接入方的權限是否能夠訪問本次請求的微服務。- 如果接入方的權限沒問題，
API網關將原請求header中附加解析後的明文Token，並將請求轉發至微服務。 - 微服務收到請求，明文
token中包含登錄用戶的身份和權限信息。因此後續微服務自己可以幹兩件事：①用戶授權攔截（看當前用戶是否有權訪問該資源）②將用戶信息存儲進當前線程上下文（有利於後續業務邏輯隨時獲取當前用戶信息）
①統一認證服務(UAA)
它承載了OAuth2.0接入方認證、登入用戶的認證、授權以及生成令牌的職責，完成實際的用戶認證、授權功能
②API網關
作爲系統的唯一入口，API網關爲接入方提供定製的API集合，它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存等。API網關方式的核心要點是，所有的接入方和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。
五、OAuth2.0介紹
OAuth（開放授權）是一個開放標準，允許用戶授權第三方應用訪問他們存儲在另外的服務提供者上的信息，而不 需要將用戶名和密碼提供給第三方應用或分享他們數據的所有內容。OAuth2.0是OAuth協議的延續版本，但不向後兼容OAuth 1.0即完全廢止了OAuth1.0。很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH認證服務，這些都足以說明OAUTH標準逐漸成爲開放資源授權的標準。
5.1 OAuth2.0使用案例
下邊分析一個Oauth2認證的例子，通過例子去理解OAuth2.0協議的認證流程，本例子是黑馬程序員網站使用微信 認證的過程，這個過程的簡要描述如下：
①客戶端請求第三方授權
用戶進入鬥魚的登錄頁面，點擊微信的圖標以QQ賬號登錄系統，用戶是自己在QQ裏信息的資源擁有者。
②資源擁有者同意給客戶端授權
點擊QQ開始給鬥魚授權，資源擁有者登錄QQ表示資源擁有者同意給客戶端授權，QQ會對資源擁有者的身份進行驗證， 驗證通過後，QQ會詢問用戶是否給授權鬥魚訪問自己的QQ數據，用戶點擊“確認登錄”表示同意授權，QQ認證服務器會頒發一個授權碼，並重定向到鬥魚的網站。
③客戶端獲取到授權碼，請求認證服務器申請令牌
此過程用戶看不到，客戶端應用程序請求認證服務器，請求攜帶授權碼。
④認證服務器向客戶端響應令牌
QQ認證服務器驗證了客戶端請求的授權碼，如果合法則給客戶端頒發令牌，令牌是客戶端訪問資源的通行證。 此交互過程用戶看不到，當客戶端拿到令牌後，用戶在鬥魚看到已經登錄成功。
⑤客戶端請求資源服務器的資源
客戶端攜帶令牌訪問資源服務器的資源，鬥魚網站攜帶令牌請求訪問QQ服務器獲取用戶的基本信息。
⑥資源服務器返回受保護資源
資源服務器校驗令牌的合法性，如果合法則向用戶響應資源信息內容
5.2 認證授權執行流程
通過上邊的例子我們大概瞭解了OAauth2.0的認證過程，下邊我們看OAuth2.0認證流程：
OAauth2.0包括以下角色：
①客戶端
本身不存儲資源，需要通過資源擁有者的授權去請求資源服務器的資源，比如：Android客戶端、Web客戶端（瀏 覽器端）、微信客戶端等。
②資源擁有者
通常爲用戶，也可以是應用程序，即該資源的擁有者。
③授權服務器（也稱認證服務器）
用於服務提供商對資源擁有的身份進行認證、對訪問資源進行授權，認證成功後會給客戶端發放令牌（access_token），作爲客戶端訪問資源服務器的憑據。本例爲微信的認證服務器。
④資源服務器
存儲資源的服務器，本例子爲QQ存儲的用戶信息。 現在還有一個問題，服務提供商能允許隨便一個客戶端就接入到它的授權服務器嗎？答案是否定的，服務提供商會給准入的接入方一個身份，用於接入時的憑據: client_id：客戶端標識;client_secret：客戶端祕鑰
因此，準確來說，授權服務器對兩種OAuth2.0中的兩個角色進行認證授權，分別是資源擁有者、客戶端。