微服務做用戶認證和授權(quán)一直都是一個難點，隨著OAuth2.0的密碼模式被作廢，更是難上加難了。今天胖哥群里的一個群友搭建用戶認證授權(quán)體系的時候遇到了一些棘手的問題，這讓胖哥覺得是時候分享一些思路出來了。

兩種思路

通常微服務的認證和授權(quán)思路有兩種：

• 所有的認證授權(quán)都由一個獨立的用戶認證授權(quán)服務器負責，它只負責發(fā)放Token，然后網(wǎng)關(guān)只負責轉(zhuǎn)發(fā)請求到各個微服務模塊，由微服務各個模塊自行對Token進行校驗處理。
• 另一種是網(wǎng)關(guān)不但承擔了流量轉(zhuǎn)發(fā)作用，還承擔認證授權(quán)流程，當前請求的認證信息由網(wǎng)關(guān)中繼給下游服務器。

第一種非常簡單，而且我在多個微服務項目中都是這樣設(shè)計的。如果你從來沒有設(shè)計過，我其實建議按這個思路去做，你只需要搞一個負責管理用戶、角色權(quán)限的服務器，其它的微服務模塊都作為資源服務器自行和這個用戶授權(quán)服務器進行交互，加上三戶模型體系就足以應對各種場景了。

第二種結(jié)合了OAuth2體系，網(wǎng)關(guān)不僅僅承擔流量轉(zhuǎn)發(fā)功能，認證授權(quán)也是在網(wǎng)關(guān)層處理的，令牌會中繼給下游服務。這種模式下需要搭建一個UAA(User Account And Authentication)服務。它非常靈活，它可以管理用戶，也可以讓受信任的客戶端自己管理用戶，它只負責對客戶端進行認證(區(qū)別于用戶認證)和對客戶端進行授權(quán)。目前使用OAuth2對微服務進行安全體系建設(shè)的都使用這種方式。

接下來分享一下我在第二種思路上的成果。

Spring Cloud Gateway 結(jié)合OAuth2提供UAA服務

用的技術(shù)有：

• Spring Cloud Gateway
• Spring Authorization Server
• Spring Security 5.0 OAuth2 Client
• OIDC 1.0

大致的思路

UAA服務器自然由 Spring Authorization Server承擔。它負責整個用戶的管理，當然你還可以分離一個專門的用戶服務器，只不過UAA需要通過Spring Cloud OpenFeign和用戶服務通信;另外它還是一個OAuth2授權(quán)服務器，管理OAuth2客戶端，處理OAuth2授權(quán)。重點來了，網(wǎng)關(guān)Gateway需要作為OAuth2客戶端注冊到UAA服務器，并作為一個OAuth2客戶端。

微服務應用

當User Agent(瀏覽器、APP)通過網(wǎng)關(guān)請求資源時：

上面執(zhí)行的是一個標準的OAuth2授權(quán)碼流程，Spring Cloud Gateway會把用戶引導到UAA服務器的登錄接口去登錄。

終端用戶登錄后進行授權(quán)確認，注意看F12的鏈路。

用戶確認

用戶勾選授權(quán)并確認后，成功訪問到了資源，同樣看調(diào)用的鏈路。

成功訪問資源

授權(quán)確認提交后，再次重定向到OAuth2授權(quán)碼登錄流程，最終獲取了資源。

我們看最終/res/foo的請求細節(jié)，居然沒有攜帶Token也拿到了用戶的所有權(quán)限。

這都是網(wǎng)關(guān)令牌中繼的功勞，前端應用很好地屏蔽了JWT令牌。

如果有多個Gateway節(jié)點和UAA節(jié)點，可能要結(jié)合Spring Session去實現(xiàn)分布式Session以及對一些客戶端信息、用戶信息進行分布式管理。

總結(jié)

通過上面流程的介紹，動手能力很強的小伙伴應該能實現(xiàn)相關(guān)的功能了。