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

1. 認證與授權(quán)

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

• 認證
• 授權(quán)

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

1.1 認證

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

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

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

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

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

這是認證方案的選擇。

1.2 授權(quán)

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

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

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

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

2. 認證服務

那么認證和授權(quán)在哪里做？

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

• 登錄
• 校驗

2.1 登錄

一般來說，登錄我們可以單獨做一個認證服務。當?shù)卿浾埱蟮竭_網(wǎng)關(guān)之后，我們將之轉(zhuǎn)發(fā)到認證服務上，完成認證操作。

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

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

2.2 校驗

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

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

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

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

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

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

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

3. 授權(quán)服務

授權(quán)沒法放到網(wǎng)關(guān)上做，還是得在各個微服務上去完成。

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

前端發(fā)送來的請求（外部請求）。

別的微服務發(fā)送來的請求（內(nèi)部請求）。

3.1 外部請求

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

3.2 內(nèi)部請求

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

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

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