聊聊微服務架構中的用戶認證方案

作者：不才陳某 2023-03-01 08:57:32

今天主要涉及三方面內容，首先咱們回顧了基于 Session 的有狀態用戶認證解決方案，其次介紹了 JWT 與 JJWT 的使用，最后講解了利用 JWT 實現微服務架構認證的兩種方案，對產生的新問題也進行了梳理。

今天來聊聊微服務中一個重要的話題：如何設計微服務架構下的用戶認證方案。今天主要涉及三個方面的內容：

傳統的用戶認證方案；
JWT 與 JJWT；
基于網關的統一用戶認證。

傳統的用戶認證方案

我們直奔主題，什么是用戶認證呢？對于大多數與用戶相關的操作，軟件系統首先要確認用戶的身份，因此會提供一個用戶登錄功能。用戶輸入用戶名、密碼等信息，后臺系統對其進行校驗的操作就是用戶認證。用戶認證的形式有多種，最常見的有輸入用戶名密碼、手機驗證碼、人臉識別、指紋識別等，但其目的都是為了確認用戶的身份并與之提供服務。

用戶認證

在傳統的單體單點應用時代，我們會開發用戶認證的服務類，從登錄界面提交的用戶名密碼等信息通過用戶認證類進行校驗，然后獲取該用戶對象將其保存在 Tomcat 的 Session 中，如下所示：

單點應用認證方案

隨著系統流量的增高，單點應用以無法支撐業務運行，應用出現高延遲、宕機等狀況，此時很多公司會將應用改為 Nginx 軟負載集群，通過水平擴展提高系統的性能，于是應用架構就變成了這個樣子。

Java Web 應用集群

雖然改造后系統性能顯著提高，但你發現了么，因為之前用戶登錄的會話數據都保存在本地，當 Nginx 將請求轉發到其他節點后，因為其他節點沒有此會話數據，系統就會認為沒有登錄過，請求的業務就會被拒絕。從使用者的角度會變成一刷新頁面后，系統就讓我重新登錄，這個使用體驗非常糟糕。

我們來分析下，這個問題的根本原因在于利用 Session 本地保存用戶數據會讓 Java Web 應用變成有狀態的，在集群環境下必須保證每一個 Tomcat 節點的會話狀態一致的才不會出問題。因此基于 Redis 的分布式會話存儲方案應運而生，在原有架構后端增加 Redis 服務器，將用戶會話統一轉存至 Redis 中，因為該會話數據是集中存儲的，所以不會出現數據一致性的問題。

Redis 統一存儲用戶會話

但是，傳統方案在互聯網環境下就會遇到瓶頸，Redis 充當了會話數據源，這也意味著 Redis 承擔了所有的外部壓力，在互聯網數以億計的龐大用戶群規模下，如果出現突發流量洪峰，Redis 能否經受考驗就會成為系統的關鍵風險，稍有差池系統就會崩潰。

那如何解決呢？其實還有一種巧妙的設計，在用戶認證成功，后用戶數據不再存儲在后端，而改為在客戶端存儲，客戶端每一次發送請求時附帶用戶數據到 Web 應用端，Java 應用讀取用戶數據進行業務處理，因為用戶數據分散存儲在客戶端中，因此并不會對后端產生額外的負擔，此時認證架構會變成下面的情況。

客戶端存儲用戶信息

當用戶認證成功后，在客戶端的 Cookie、LocalStorage 會持有當前用戶數據，在 Tomcat 接收到請求后便可獲取用戶數據進行業務處理。但細心的你肯定也發現，用戶的敏感數據是未經過加密的，在存儲與傳輸過程中隨時都有泄密的風險，決不能使用明文，必須要對其進行加密。

那如何進行加密處理呢？當然，你可以自己寫加解密類，但更通用的做法是使用 JWT 這種標準的加密方案進行數據存儲與傳輸。

Json Web Token（JWT）介紹

無論是微服務架構，還是前后端分離應用，在客戶端存儲并加密數據時有一個通用的方案：Json Web Token（JWT），JWT是一個經過加密的，包含用戶信息的且具有時效性的固定格式字符串。下面這是一個標準的JWT字符串。

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ7XCJ1c2VySWRcIjoyLFwidXNlcm5hbWVcIjpcImxpc2lcIixcIm5hbWVcIjpcIuadjuWbm1wiLFwiZ3JhZGVcIjpcInZpcFwifSJ9.NT8QBdoK4S-PbnhS0msJAqL0FG2aruvlsBSyG226HiU

這段加密字符串由三部分組成，中間由點“.”分隔，具體含義如下。

第一部分標頭（Header）：標頭通常由兩部分組成：令牌的類型（即 JWT）和所使用的簽名算法，例如 HMAC SHA256 或 RSA，下面是標頭的原文：

{  
  "alg": "HS256",  
  "typ": "JWT"  
}

然后，此 JSON 被 Base64 編碼以形成 JWT 的第一部分。

eyJhbGciOiJIUzI1NiJ9

第二部分載荷（Payload）：載荷就是實際的用戶數據以及其他自定義數據。載荷原文如下所示。

{  
  "sub": "1234567890",  
  "name": "John Doe",  
  "admin": true  
}

然后對原文進行 Base64 編碼形成 JWT 的第二部分。

eyJzdWIiOiJ7XCJ1c2VySWRcIjoyLFwidXNlcm5hbWVcIjpcImxpc2lcIixcIm5hbWVcIjpcIuadjuWbm1wiLFwiZ3JhZGVcIjpcInZpcFwifSJ9

第三部分簽名（Sign）：簽名就是通過前面兩部分標頭+載荷+私鑰再配合指定的算法，生成用于校驗 JWT 是否有效的特殊字符串，簽名的生成規則如下。

HMACSHA256(base64UrlEncode(header) + "." +  base64UrlEncode(payload),  secret)

生成的簽名字符串為：

NT8QBdoK4S-PbnhS0msJAqL0FG2aruvlsBSyG226HiU

將以上三部分通過“.”連接在一起，就是 JWT 的標準格式了。

JWT 的創建與校驗

此時，你肯定有疑問 JWT 是如何生成的，又是如何完成有效性校驗呢？因為 JWT 的格式與算法是固定的，在 Java 就有非常多的優秀開源項目幫我們實現了JWT 的創建與驗簽，其中最具代表性的產品就是 JJWT。JJWT 是一個提供端到端的 JWT 創建和驗證的 Java 庫，它的官網是：https://github.com/jwtk/jjwt，有興趣的話你可以到官網閱讀它的源碼。

JJWT 的使用是非常簡單的，下面我們用代碼進行說明，關鍵代碼我已做好注釋。

第一步，pom.xml 引入 JJWT 的 Maven 依賴。

<dependency>  
    <groupId>io.jsonwebtoken</groupId>  
    <artifactId>jjwt-api</artifactId>  
    <version>0.11.2</version>  
</dependency>  
  
<dependency>  
    <groupId>io.jsonwebtoken</groupId>  
    <artifactId>jjwt-impl</artifactId>  
    <version>0.11.2</version>  
    <scope>runtime</scope>  
</dependency>  
  
<dependency>  
    <groupId>io.jsonwebtoken</groupId>  
    <artifactId>jjwt-jackson</artifactId> <!-- or jjwt-gson if Gson is preferred -->  
    <version>0.11.2</version>  
    <scope>runtime</scope>  
</dependency>

第二步，編寫創建 JWT 的測試用例，模擬真實環境 UserID 為 123 號的用戶登錄后的 JWT 生成過程。

@SpringBootTest  
public class JwtTestor {  
    /**  
     * 創建Token  
     */  
    @Test  
    public void createJwt(){  
        //私鑰字符串  
        String key = "1234567890_1234567890_1234567890";  
        //1.對秘鑰做BASE64編碼  
        String base64 = new BASE64Encoder().encode(key.getBytes());  
        //2.生成秘鑰對象,會根據base64長度自動選擇相應的 HMAC 算法  
        SecretKey secretKey = Keys.hmacShaKeyFor(base64.getBytes());  
        //3.利用JJWT生成Token  
        String data = "{\"userId\":123}"; //載荷數據  
        String jwt = Jwts.builder().setSubject(data).signWith(secretKey).compact();  
        System.out.println(jwt);  
    }  
}

運行結果產生 JWT 字符串如下：

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ7XCJ1c2VySWRcIjoxMjN9In0.1p_VTN46sukRJTYFxUg93CmfR3nJZRBm99ZK0e3d9Hw

第三步，驗簽代碼，從 JWT 中提取 123 號用戶數據。這里要保證 JWT 字符串、key 私鑰與生成時保持一致。否則就會拋出驗簽失敗 JwtException。

/**  
 * 校驗及提取JWT數據  
 */  
@Test  
public void checkJwt(){  
    String jwt = "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ7XCJ1c2VySWRcIjoxMjN9In0.1p_VTN46sukRJTYFxUg93CmfR3nJZRBm99ZK0e3d9Hw";  
    //私鑰  
    String key = "1234567890_1234567890_1234567890";  
    //1.對秘鑰做BASE64編碼  
    String base64 = new BASE64Encoder().encode(key.getBytes());  
    //2.生成秘鑰對象,會根據base64長度自動選擇相應的 HMAC 算法  
    SecretKey secretKey = Keys.hmacShaKeyFor(base64.getBytes());  
    //3.驗證Token  
    try {  
        //生成JWT解析器   
        JwtParser parser = Jwts.parserBuilder().setSigningKey(secretKey).build();  
        //解析JWT  
        Jws<Claims> claimsJws = parser.parseClaimsJws(jwt);  
        //得到載荷中的用戶數據  
        String subject = claimsJws.getBody().getSubject();  
        System.out.println(subject);  
    }catch (JwtException e){  
        //所有關于Jwt校驗的異常都繼承自JwtException  
        System.out.println("Jwt校驗失敗");  
        e.printStackTrace();  
    }  
}

運行結果如下：

{"userId":123}

以上便是 JWT 的生成與校驗代碼，你會發現在加解密過程中，服務器私鑰 key 是保障 JWT 安全的命脈。對于這個私鑰在生產環境它不能寫死在代碼中，而是加密后保存在 Nacos 配置中心統一存儲，同時定期更換私鑰以防止關鍵信息泄露。

講到這應該你已掌握 JWT 的基本用法，但是在微服務架構下又該如何設計用戶認證體系呢？

基于網關的統一用戶認證

關于網關統一用戶認證和鑒權可以看陳某之前的文章：實戰干貨！Spring Cloud Gateway 整合 OAuth2.0 實現分布式統一認證授權！

下面我們結合場景講解 JWT 在微服務架構下的認證過程。這里我將介紹兩種方案：

服務端自主驗簽方案；
API 網關統一驗簽方案。

服務端自主驗簽方案

首先咱們來看服務端驗簽的架構圖。

服務端自主驗簽方案

首先梳理下執行流程：

第一步，認證中心微服務負責用戶認證任務，在啟動時從 Nacos 配置中心抽取 JWT 加密用私鑰；
第二步，用戶在登錄頁輸入用戶名密碼，客戶端向認證中心服務發起認證請求：

http://usercenter/login #認證中心用戶認證（登錄）地址

第三步，認證中心服務根據輸入在用戶數據庫中進行認證校驗，如果校驗成功則返回認證中心將生成用戶的JSON數據并創建對應的 JWT 返回給客戶端，下面是認證中心返回的數據樣本；

{  
    "code": "0",  
    "message": "success",  
    "data": {  
        "user": {  
            "userId": 1,  
            "username": "zhangsan",  
        },  
        "token": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ7XCJ1c2VySWRcIjoxLFwidXNlcm5hbWVcIjpcInpoYW5nc2FuXCIsXCJuYW1lXCI6XCLlvKDkuIlcIixcImdyYWRlXCI6XCJub3JtYWxcIn0ifQ.1HtfszarTxLrqPktDkzArTEc4ah5VO7QaOOJqmSeXEM"  
    }  
}

第四步，在收到上述 JSON 數據后，客戶端將其中 token 數據保存在 cookie 或者本地緩存中；
第五步，隨后客戶端向具體某個微服務發起新的請求，這個 JWT 都會附加在請求頭或者 cookie 中發往 API 網關，網關根據路由規則將請求與jwt數據轉發至具體的微服務。中間過程網關不對 JWT 做任何處理；
第六步，微服務接收到請求后，發現請求附帶 JWT 數據，于是將 JWT 再次轉發給用戶認證服務，此時用戶認證服務對 JWT 進行驗簽，驗簽成功提取其中用戶編號，查詢用戶認證與授權的詳細數據，數據結構如下所示：

{  
    "code": "0",  
    "message": "success",  
    "data": {  
        "user": { #用戶詳細數據  
            "userId": 1,  
            "username": "zhangsan",  
            "name": "張三",  
            "grade": "normal"  
            "age": 18,  
            "idno" : 130.......,  
            ...  
        },  
        "authorization":{ #權限數據  
            "role" : "admin",  
            "permissions" : [{"addUser","delUser","..."}]  
        }  
    }  
}

第七步，具體的微服務收到上述 JSON 后，對當前執行的操作進行判斷，檢查是否擁有執行權限，權限檢查通過執行業務代碼，權限檢查失敗返回錯誤響應。

到此從登錄創建 JWT 到驗簽后執行業務代碼的完整流程已經完成。

下面咱們來聊一聊第二種方案：

API 網關統一驗簽方案

API 網關統一驗簽與服務端驗簽最大的區別是在 API 網關層面就發起 JWT 的驗簽請求，之后路由過程中附加的是從認證中心返回的用戶與權限數據，其他的操作步驟與方案一是完全相同的。

在這你可能又會有疑惑，為什么要設計兩種不同的方案呢？其實這對應了不同的應用場景：

服務端驗簽的時機是在業務代碼執行前，控制的粒度更細。比如微服務 A 提供了“商品查詢”與“創建訂單”兩個功能，前者不需要登錄用戶就可以使用，因此不需要向認證中心額外發起驗簽工作；而后者是登錄后的功能，因此必須驗簽后才可執行。因為服務端驗簽是方法層面上的，所以可以精確控制方法是否驗簽。但也有不足，正是因為驗簽是在方法前執行，所以需要在所有業務方法上聲明是否需要額外驗簽，盡管這個工作可以通過 Spring AOP+注解的方式無侵入實現，但這也無疑需要程序員額外關注，分散了開發業務的精力。

相應的，服務端驗簽的缺點反而成為 API 網關驗簽的優勢。API 網關不關心后端的服務邏輯，只要請求附帶 JWT，就自動向認證中心進行驗簽。這種簡單粗暴的策略確實讓模塊耦合有所降低，處理起來也更簡單，但也帶來了性能問題，因為只要請求包含 JWT 就會產生認證中心的遠程通信。如果前端工程師沒有對 JWT 進行精確控制，很可能帶來大量多余的認證操作，系統性能肯定會受到影響。

那在項目中到底如何選擇呢？服務端驗簽控制力度更細，適合應用在低延遲、高并發的應用，例如導航、實時交易系統、軍事應用。而 API 統一網關則更適合用在傳統的企業應用，可以讓程序員專心開發業務邏輯，同時程序也更容易維護。

全新的挑戰

雖然 JWT 看似很美，在實施落地過程中也會遇到一些特有的問題，例如：

WT 生成后失效期是固定的，很多業務中需要客戶端在不改變 JWT 的前提下，實現 JWT 的“續簽”功能，但這單靠 JWT 自身特性是無法做到的，因為 JWT 的設計本身就不允許生成完全相同的字符串。為了解決這個問題，很多項目在生成的 JWT 設為“永久生效”，架構師利用 Redis 的 Expire 過期特性在后端控制 JWT 的時效性。這么做雖然讓 JWT 本身變得有狀態，但這可能也是在各種權衡后的“最優解”。類似的，例如：強制 JWT 立即失效、動態 JWT 有效期都可以使用這個辦法解決。

某個 JWT 在 3600 秒后過期

對于上面兩種認證方案，還有優化的空間，比如在服務A第一次對某個 JWT 進行驗簽后獲取用戶與權限數據，那在 JWT 的有效期內便可將數據在本地內存或者 Redis 中進行緩存，這樣下一次同樣的 JWT 訪問時直接從緩存中提取即可，可以節省大量服務間通信時間。但引入緩存后你也要時刻關注緩存與用戶數據的一致性問題，是要性能還是要數據可靠，這又是一個架構師需要面對的抉擇。

小結

在多年的架構生涯中，我自己也在不斷感慨，架構是一門取舍的藝術，沒有完美的架構，只有適合的場景，希望未來同學們可以多學習一些前沿技術，興許隨著技術發展沒準魚和熊掌真的可以兼得呢。

責任編輯：武曉燕來源：碼猿技術專欄

微服務架構用戶認證