建站
咨詢
售后
建站咨詢
新聞中心
兩種思路
通常微服務的認證和授權思路有兩種：
- 所有的認證授權都由一個獨立的用戶認證授權服務器負責，它只負責發(fā)放Token，然后網關只負責轉發(fā)請求到各個微服務模塊，由微服務各個模塊自行對Token進行校驗處理。
- 另一種是網關不但承擔了流量轉發(fā)作用，還承擔認證授權流程，當前請求的認證信息由網關中繼給下游服務器。
第一種非常簡單，而且我在多個微服務項目中都是這樣設計的。如果你從來沒有設計過，我其實建議按這個思路去做，你只需要搞一個負責管理用戶、角色權限的服務器，其它的微服務模塊都作為資源服務器自行和這個用戶授權服務器進行交互，加上三戶模型體系就足以應對各種場景了。
第二種結合了OAuth2體系，網關不僅僅承擔流量轉發(fā)功能，認證授權也是在網關層處理的，令牌會中繼給下游服務。這種模式下需要搭建一個UAA(User Account And Authentication)服務。它非常靈活，它可以管理用戶，也可以讓受信任的客戶端自己管理用戶，它只負責對客戶端進行認證(區(qū)別于用戶認證)和對客戶端進行授權。目前使用OAuth2對微服務進行安全體系建設的都使用這種方式。
接下來分享一下我在第二種思路上的成果。
Spring Cloud Gateway 結合OAuth2提供UAA服務
用的技術有：
- Spring Cloud Gateway
- Spring Authorization Server
- Spring Security 5.0 OAuth2 Client
- OIDC 1.0
大致的思路
UAA服務器自然由 Spring Authorization Server承擔。它負責整個用戶的管理，當然你還可以分離一個專門的用戶服務器，只不過UAA需要通過Spring Cloud OpenFeign和用戶服務通信;另外它還是一個OAuth2授權服務器，管理OAuth2客戶端，處理OAuth2授權。重點來了，網關Gateway需要作為OAuth2客戶端注冊到UAA服務器，并作為一個OAuth2客戶端。
微服務應用
當User Agent(瀏覽器、APP)通過網關請求資源時：
上面執(zhí)行的是一個標準的OAuth2授權碼流程，Spring Cloud Gateway會把用戶引導到UAA服務器的登錄接口去登錄。
終端用戶登錄后進行授權確認，注意看F12的鏈路。
用戶確認
用戶勾選授權并確認后，成功訪問到了資源，同樣看調用的鏈路。
成功訪問資源
授權確認提交后，再次重定向到OAuth2授權碼登錄流程，最終獲取了資源。
我們看最終/res/foo的請求細節(jié)，居然沒有攜帶Token也拿到了用戶的所有權限。
這都是網關令牌中繼的功勞，前端應用很好地屏蔽了JWT令牌。
如果有多個Gateway節(jié)點和UAA節(jié)點，可能要結合Spring Session去實現(xiàn)分布式Session以及對一些客戶端信息、用戶信息進行分布式管理。
總結
通過上面流程的介紹，動手能力很強的小伙伴應該能實現(xiàn)相關的功能了。
當前題目：SpringCloudGateway整合OAuth2思路分享
文章來源：http://www.5511xx.com/article/cojpcde.html
