最近剛好有小伙伴在微信上問到這個問題，松哥就來和大家聊一聊，本文主要和小伙伴們聊一聊思路，不寫代碼，小伙伴們可以結合松哥之前的文章，應該能夠自己寫出來本文的代碼。當然，思路也只是我自己的一點實踐經驗，不一定是最完美的方案，歡迎小伙伴們在留言中一起探討。

1. 認證與授權

首先小伙伴們知道，無論我們學習 Shiro 還是 Spring Security，里邊的功能無論有哪些，核心都是兩個：

• 認證
• 授權

所以，我們在微服務中處理鑒權問題，也可以從這兩個方面來考慮。

1.1 認證

認證，說白了就是登錄。傳統的 Web 登錄是 Cookie+Session 的方案，這種方案依賴于服務器本地內存，在微服務中，由于服務眾多，這種方案顯然不再合適。

可能會有小伙伴說用 Redis+SpringSession 做 Session 共享，這是個辦法，但是不是最佳方案，因為這種方案的性能以及可擴展性都比較差。

所以，微服務中的認證，還是建議使用令牌的方式，可以選擇 JWT 令牌，這也是目前使用較多的一種方案。但是熟悉 JWT 的小伙伴都知道，純粹的無狀態登錄無法實現注銷，這就很頭大，所以在實際應用中，單純的使用 JWT 是不行的，一般還是要結合 Redis 一起，將生成的 JWT 字符串在 Redis 上也保存一份，并設置過期時間，判斷用戶是否登錄時，需要先去 Redis 上查看 JWT 字符串是否存在，存在的話再對 JWT 字符串做解析操作，如果能成功解析，就沒問題，如果不能成功解析，就說明令牌不合法。

這樣有狀態登錄+無狀態登錄混在一起的方式，雖然看起來有點不倫不類，但是就當下來說，這個折衷的辦法算是一個可行的方案了。

其實，上面的方案，說白了，跟傳統的 Cookie+Session 沒什么兩樣，思路幾乎都是完全 copy 的：傳統的 Session 用 Redis 代替了；傳統穿梭于服務端和瀏覽器之間的 jsessionId 被 JWT 字符串代替了；傳統的 jsessionId 通過 Cookie 來傳輸，現在的 JWT 則通過開發者手動設置后通過請求頭來傳輸；傳統的 Session 可以自動續簽，現在用 JWT 就是手動續簽，每次請求到達服務端的時候，就去看下 Redis 上令牌的過期時間，快過期了，就重新設置一下，其他都一模一樣。

這是認證方案的選擇。

1.2 授權

微服務中授權，也可以使用 Shiro 或者 Spring Security 框架來做，省事一些?？紤]到微服務技術棧都是 Spring 家族的產品，所以在權限框架這塊也是建議大家首選 Spring Security（如果有小伙伴對 Spring Security 還不熟悉的話，可以在微信公眾號后臺回復 ss，有教程）。

當然，如果覺得 Spring Security 比較復雜想自己搞的話，也是可以的。自己搞的話，也是可以借助于 Spring Security 的思路的，松哥最近的一個項目就是這樣：

請求到達微服務之后，先找到當前用戶的各種信息，包括當前用戶所擁有的角色和權限等信息，然后存入到和當前線程綁定的 ThreadLocal 對象中。另一方面自定義權限注解和角色注解，在切面中對這些注解進行解析，檢查當前用戶是否具備所需要的角色/權限等。

當然，如果你使用了 Spring Security 的話，上面這個就不需要自定義注解了，直接使用 Spring Security 中自帶的即可，還可以體驗 Spring Security 中更多的豐富的安全功能。

2. 認證服務

那么認證和授權在哪里做？

先來說認證，認證我們可以簡單分為兩個步驟：

• 登錄
• 校驗

2.1 登錄

一般來說，登錄我們可以單獨做一個認證服務。當登錄請求到達網關之后，我們將之轉發到認證服務上，完成認證操作。

在認證服務上，我們就去檢查用戶名/密碼是否 OK，用戶狀態是否都 OK，都沒問題的話，生成 JWT 字符串，同時再把數據存入到 Redis 上，然后把 JWT 字符串返回。

如果系統有注冊功能的話，注冊功能也是放在這個微服務上來完成。

2.2 校驗

校驗是指每一個請求到達的時候，校驗用戶是否已經登錄。

這個當然可以和 2.1 放到一起去做，但是松哥不建議。問題在于，假如是一個創建訂單的請求，這個請求原本是要經過網關轉發到訂單服務上的，但是，此時就得先在網關上調用 2.1 小節的服務進行登錄校驗，沒問題再轉發到訂單服務上，這樣做很明顯很費事，也不合理。

一個比較好的辦法是直接在網關上去校驗請求的令牌是否合法，這個校驗本身也比較容易，校驗令牌是否合法，我們只需要看 Redis 上是否存在這個令牌，并且這個 JWT 令牌能夠被順利解析就行，這個操作完全可以在網關上做。

以 Gateway 網關為例，我們可以自定義全局過濾器，在全局過濾器中校驗每一個請求的令牌，校驗通過了，再進行請求的轉發，否則就不轉發。

校驗通過之后，在轉發到具體的微服務之后，我們可以將解析出來的用戶 id 以及用戶名等信息放到請求頭中，然后再轉發，這樣到達各個具體的微服務之后，就知道這個請求是誰發來的，這人都有哪些角色/權限，方便做下一步的權限校驗。

松哥的做法是定義了一個公共模塊，所有的微服務都依賴這個公共模塊，這個公共模塊中定義了一個攔截器，會攔截下來每一個請求，從請求頭中取出用戶 ID，然后從 Redis 中拿到具體的用戶信息，存入到 ThreadLocal 中，這樣在后續的方法調用中，如果需要判斷用戶是否具備某一個權限，就可以通過 ThreadLocal 去獲取了。

大致上就是這樣一個流程。

3. 授權服務

授權沒法放到網關上做，還是得在各個微服務上去完成。

微服務上的授權我們又可以將之大致上分為兩類：

前端發送來的請求（外部請求）。

別的微服務發送來的請求（內部請求）。

3.1 外部請求

對于外部請求來說，就按正常的權限校驗對待就行了，自定義注解亦或者使用 Spring Security 等框架都是可以的，如果是自定義注解的話，就結合 AOP 一起，定義切面自己去處理權限注解，當然，這些功能基本上每一個微服務都是需要的，所以可以將之抽取成為一個公共的模塊，在不同的微服務中依賴即可。

3.2 內部請求

對于內部的請求來說，正常是不需要鑒權的，內部請求可以直接處理。問題是如果使用了 OpenFeign，數據都是通過接口暴露出去的，不鑒權的話，又會擔心從外部來的請求調用這個接口，對于這個問題，我們也可以自定義注解+AOP，然后在內部請求調用的時候，額外加一個頭字段加以區分。

當然，內部請求到達微服務的時候，也是需要進行認證的，就行請求從網關轉發到每一個具體的微服務上時需要認證一樣，不過很明顯，我們沒必要每次使用 OpenFeign 調用別的服務的時候，都去傳一堆認證信息，我們可以通過實現 feign.RequestInterceptor 接口來定義一個 OpenFeign 的請求攔截器，在攔截器中，統一為 OpenFeign 請求設置請求頭信息。

好啦，關于微服務中的鑒權，我們目前是這么做的，歡迎小伙伴們留言一起探討。