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

前言

前面我們討論的是SpringSecurity基礎(chǔ)部分內(nèi)容，接下來我們來探討一下SpringCloud 集成 SpringSecurity和Oauth實(shí)現(xiàn)微服務(wù)認(rèn)證授權(quán)方案

微服務(wù)(分布式)項(xiàng)目常見認(rèn)證方案

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

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

Session不同步問題如圖：

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

2.1.CAS單點(diǎn)登錄

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

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

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

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

• 瀏覽器(同一個(gè)瀏覽器)訪問另外一個(gè)客戶端系統(tǒng)B，系統(tǒng)B檢查到?jīng)]有登錄，請(qǐng)求重定向到認(rèn)證中心
• 由于瀏覽器在訪問系統(tǒng)A的時(shí)候已經(jīng)到了登錄，cookie中有TGC,所以認(rèn)證中心可以獲取到TGC找到對(duì)應(yīng)的TGT
• 認(rèn)證中心根據(jù)cookie中的TGC找到TGT，代表用戶登錄過，于是創(chuàng)建ticket,并重定向請(qǐng)求到系統(tǒng)B，帶著參數(shù)ticket
• 系統(tǒng)B接收到請(qǐng)求，拿著ticket去認(rèn)證中心校驗(yàn)Ticket
• 認(rèn)證中心ticket校驗(yàn)通過，返回用戶信息

這種方案意味著每個(gè)面向用戶的服務(wù)都必須與認(rèn)證服務(wù)交互，這會(huì)產(chǎn)生大量非?，嵥榈木W(wǎng)絡(luò)流量和重復(fù)的工作，當(dāng)動(dòng)輒數(shù)十個(gè)微應(yīng)用時(shí)，這種方案的弊端會(huì)更加明顯，而且這種方案不太適合移動(dòng)端認(rèn)證方案。

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

這種方案是在網(wǎng)關(guān)做登錄，以及登錄檢查，登錄會(huì)話通過Redis進(jìn)行分布式會(huì)話存儲(chǔ)，后端微服務(wù)可以從共享會(huì)話Redis中獲取認(rèn)證信息，當(dāng)然這里我們可以使用Redis的 key 來生成一個(gè)Token然后相應(yīng)給客戶端，客戶端存儲(chǔ)Token。當(dāng)訪問資源的時(shí)候攜帶者Token去后臺(tái)，在網(wǎng)關(guān)層根據(jù)Token檢查分布式會(huì)話是否完成登錄。

• 客戶端發(fā)起請(qǐng)求，網(wǎng)關(guān)實(shí)現(xiàn)登錄邏輯，登錄信息存儲(chǔ)到Redis，并且根據(jù)Redis的key創(chuàng)建一個(gè)Token
• 將Token返回給瀏覽器，瀏覽器將Token存儲(chǔ)起來
• 瀏覽器在訪問資源的時(shí)候請(qǐng)求到網(wǎng)關(guān)并攜帶Token,網(wǎng)關(guān)獲取到Token，從Redis中獲取用戶登錄信息做檢查，沒有問題就繼續(xù)轉(zhuǎn)發(fā)Token到后續(xù)服務(wù)。
• 在后續(xù)服務(wù)中可以通過Token去Redis中獲取認(rèn)證信息。

這種方案需要注意對(duì)共享會(huì)有一定的保護(hù)機(jī)制，并且實(shí)現(xiàn)也有一定的實(shí)現(xiàn)難度

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

客戶端Token是一種比較常用的認(rèn)證方案，有點(diǎn)在于Token中攜帶了用戶信息在服務(wù)之間傳輸，做到了無狀態(tài)，可以通過JWT等安全機(jī)制加密Token保證Token的安全性

• 客戶端發(fā)起認(rèn)證請(qǐng)求，使用JWT等加密方式生成安全的 Token，Token中攜帶了認(rèn)證授權(quán)信息，然后返回給客戶端，
• 客戶端存儲(chǔ)Token，后續(xù)客戶端需要訪問資源時(shí)，攜帶者Token請(qǐng)求。
• 客戶端發(fā)起請(qǐng)求，在網(wǎng)關(guān)層對(duì)Token進(jìn)行統(tǒng)一檢查，檢查通過Token繼續(xù)攜帶到后端訪問中如果涉及到大量的用戶信息的存放，可以使用Redis來進(jìn)行存儲(chǔ)。
• 后續(xù)服務(wù)獲取到Token即可獲取到用戶信息

客戶端Token方案的好處在于可以做到無狀態(tài)，因?yàn)門oken中包含了用戶信息，服務(wù)端不用考慮存儲(chǔ)用戶信息，缺點(diǎn)在于Token過長(zhǎng)造成的網(wǎng)絡(luò)傳輸?shù)拈_銷。

2.4.其他方案

當(dāng)然解決單點(diǎn)登錄還有其他方案，比如使用SpirngSession+Redis實(shí)現(xiàn)Session共享，或是配置服務(wù)器之間的Session同步，亦或是使用Nginx的負(fù)載均衡策略u(píng)rl hash一致性來解決，總歸來說解決方案五花八門，選擇適合項(xiàng)目的方案是最重要的

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

現(xiàn)在比較流程的微服務(wù)架構(gòu)是SpringCloud的微服務(wù)架構(gòu)，比較推薦的授權(quán)方案是SpringCloud+SpringSecurity+OAuth2+JWT+Zuul，其實(shí)這是基于客戶端Token加Zuul統(tǒng)一授權(quán)方案，如下：

解釋：

• 客戶端 : web端，移動(dòng)端，三方程序
• 認(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ù)：用戶對(duì)資源的訪問權(quán)限檢查和返回資源

它的大概流程是：

• 客戶端向認(rèn)證服務(wù)發(fā)起認(rèn)證請(qǐng)求，認(rèn)證服務(wù)執(zhí)行認(rèn)證流程
• 認(rèn)證成功，認(rèn)證服務(wù)根據(jù)用戶認(rèn)證信息，授權(quán)信息頒發(fā)Token，Token中包含了認(rèn)證授權(quán)信息
• 客戶端存儲(chǔ)Token，并向資源服務(wù)發(fā)起請(qǐng)求，請(qǐng)求頭攜帶Token
• 請(qǐng)求先到達(dá)Zuul網(wǎng)關(guān)，我們可以在網(wǎng)關(guān)層校驗(yàn)Token，當(dāng)然也可以不在網(wǎng)關(guān)層校驗(yàn)Token，而是在每個(gè)資源服務(wù)器上校驗(yàn)Token
• Token校驗(yàn)通過，資源服務(wù)獲取到Token中的權(quán)限信息對(duì)資源進(jìn)行授權(quán)，授權(quán)成功返回資源數(shù)據(jù)，授權(quán)失敗返回錯(cuò)誤
• 如果請(qǐng)求需要多個(gè)資源服務(wù)共同完成，那么我們還需要考慮在服務(wù)調(diào)用的使用把Token通過請(qǐng)求頭傳遞給下一個(gè)被調(diào)用的微服務(wù)進(jìn)行授權(quán)

當(dāng)然也可以不通過zuul統(tǒng)一授權(quán)，方案如SpringCloud+SpringSecurity+OAuth2+JWT ：

歡迎關(guān)注“Java引導(dǎo)者”，我們分享最有價(jià)值的Java的干貨文章，助力您成為有思想的Java開發(fā)工程師！