SpringCloud 微服務(wù)認(rèn)證授權(quán)方案（圖文版）

1.微服務(wù)授權(quán)面臨哪些問題

在微服務(wù)架構(gòu)下有很多的服務(wù)，每個微應(yīng)用都需要對訪問進(jìn)行認(rèn)證檢查和權(quán)限控制，客戶端發(fā)起一個請求需要考慮如何讓用戶的認(rèn)證狀態(tài)通知到所有的微服務(wù)中，尤其是請求來源于多種客戶端如瀏覽器，移動端，三方程序，服務(wù)之間訪問時，微服務(wù)的授權(quán)變得更加麻煩，再加上本地Session在微服務(wù)(集群/分布式)環(huán)境中存在Session不同步的問題，所以我們微服務(wù)授權(quán)是非常非常復(fù)雜的。

Session不同步問題如圖：

2.微服務(wù)常見認(rèn)證方案

2.1.CAS單點登錄

CAS是一種基于Cookie實現(xiàn)的單點登錄方案，頁是一個比較老的解決方案，是 Yale 大學(xué)發(fā)起的一個開源項目，旨在為 Web 應(yīng)用系統(tǒng)提供一種可靠的單點登錄方法，它分為 CAS Server端和CAS Client端，Server端負(fù)責(zé)用戶的登錄流程，Client端需要整合到各個系統(tǒng)中，它的登錄流程如下：

系統(tǒng)A的訪問流程：

• 瀏覽器請求系統(tǒng)A，系統(tǒng)A檢查到?jīng)]有登錄，重定向到認(rèn)證服務(wù)，并且攜帶參數(shù)service，這個參數(shù)的作用是在認(rèn)證中心認(rèn)證通過之后會再跳回系統(tǒng)A的重定向地址

• 請求跳轉(zhuǎn)到認(rèn)證中心，認(rèn)證中心接收到請求，返回登錄頁面，用戶提交登錄信息
• 認(rèn)證中心執(zhí)行登錄邏輯，認(rèn)證成功，生成ticket（ST）和 TGC，認(rèn)證中心會將TGC寫到瀏覽器的cookie，有這個東西說明用戶登錄過，通過TGC可以找到TGT
• 然后認(rèn)證中心將請求再重定向到系統(tǒng)A(根據(jù)之間的service參數(shù)回調(diào)地址)，并且攜帶一個ticket參數(shù)
• 請求跳轉(zhuǎn)回了系統(tǒng)A，系統(tǒng)A得到ticket，向認(rèn)證中心發(fā)起請求校驗ticket的合法性

• 認(rèn)證中心驗證ticket通過，向client返回對應(yīng)的用戶信息

• 瀏覽器(同一個瀏覽器)訪問另外一個客戶端系統(tǒng)B，系統(tǒng)B檢查到?jīng)]有登錄，請求重定向到認(rèn)證中心

• 由于瀏覽器在訪問系統(tǒng)A的時候已經(jīng)到了登錄，cookie中有TGC,所以認(rèn)證中心可以獲取到TGC找到對應(yīng)的TGT
• 認(rèn)證中心根據(jù)cookie中的TGC找到TGT，代表用戶登錄過，于是創(chuàng)建ticket,并重定向請求到系統(tǒng)B，帶著參數(shù)ticket
• 系統(tǒng)B接收到請求，拿著ticket去認(rèn)證中心校驗Ticket

• 認(rèn)證中心ticket校驗通過，返回用戶信息

2.2.分布式Session(會話)+網(wǎng)關(guān)

• 客戶端發(fā)起請求，網(wǎng)關(guān)實現(xiàn)登錄邏輯，登錄信息存儲到Redis，并且根據(jù)Redis的key創(chuàng)建一個Token

• 將Token返回給瀏覽器，瀏覽器將Token存儲起來
• 瀏覽器在訪問資源的時候請求到網(wǎng)關(guān)并攜帶Token,網(wǎng)關(guān)獲取到Token，從Redis中獲取用戶登錄信息做檢查，沒有問題就繼續(xù)轉(zhuǎn)發(fā)Token到后續(xù)服務(wù)。

• 在后續(xù)服務(wù)中可以通過Token去Redis中獲取認(rèn)證信息。

2.3.客戶端Token+網(wǎng)關(guān)

• 客戶端發(fā)起認(rèn)證請求，使用JWT等加密方式生成安全的 Token，Token中攜帶了認(rèn)證授權(quán)信息，然后返回給客戶端，

• 客戶端存儲Token，后續(xù)客戶端需要訪問資源時，攜帶者Token請求。
• 客戶端發(fā)起請求，在網(wǎng)關(guān)層對Token進(jìn)行統(tǒng)一檢查，檢查通過Token繼續(xù)攜帶到后端訪問中如果涉及到大量的用戶信息的存放，可以使用Redis來進(jìn)行存儲。

• 后續(xù)服務(wù)獲取到Token即可獲取到用戶信息

2.4.其他方案

2.5.我選擇的微服務(wù)認(rèn)證授權(quán)方案

解釋：

• 客戶端 : web端，移動端，三方程序
• 認(rèn)證服務(wù)：Oauth2授權(quán)服務(wù)：負(fù)責(zé)認(rèn)證邏輯(登錄)和頒發(fā)令牌(token)等
• 網(wǎng)關(guān)：Oauth2資源服務(wù)：負(fù)責(zé)token統(tǒng)一鑒權(quán)

• 資源服務(wù)：用戶對資源的訪問權(quán)限檢查和返回資源

• 客戶端向認(rèn)證服務(wù)發(fā)起認(rèn)證請求，認(rèn)證服務(wù)執(zhí)行認(rèn)證流程
• 認(rèn)證成功，認(rèn)證服務(wù)根據(jù)用戶認(rèn)證信息，授權(quán)信息頒發(fā)Token，Token中包含了認(rèn)證授權(quán)信息
• 客戶端存儲Token，并向資源服務(wù)發(fā)起請求，請求頭攜帶Token
• 請求先到達(dá)Zuul網(wǎng)關(guān)，我們可以在網(wǎng)關(guān)層校驗Token，當(dāng)然也可以不在網(wǎng)關(guān)層校驗Token，而是在每個資源服務(wù)器上校驗Token
• Token校驗通過，資源服務(wù)獲取到Token中的權(quán)限信息對資源進(jìn)行授權(quán)，授權(quán)成功返回資源數(shù)據(jù)，授權(quán)失敗返回錯誤

• 如果請求需要多個資源服務(wù)共同完成，那么我們還需要考慮在服務(wù)調(diào)用的使用把Token通過請求頭傳遞給下一個被調(diào)用的微服務(wù)進(jìn)行授權(quán)