目錄

通過本文你會掌握以下知識點：

• 如何用認證服務做登錄認證。
• 如何生成 JWT 令牌(Token)
• 如何用 Gateway 對 Token 驗證。
• Gateway 如何從 Token 中拿到用戶信息并轉(zhuǎn)發(fā)給業(yè)務服務。
• 業(yè)務服務如何從請求中拿到身份信息處理業(yè)務邏輯。
• 如何刷新令牌。

本篇還是基于我的開源項目 PassJava 作為講解。

PassJava 開源地址：https://github.com/Jackson0714/PassJava-Platform

在講解之前有必要澄清下什么是認證、授權(quán)、憑證，這三個方面是一個系統(tǒng)中最基礎的安全設計。

認證、授權(quán)、憑證

1.1 認證（Authentication）

認證表示你是誰。系統(tǒng)如何正確分辨出操作用戶的真實身份，比如通過輸入用戶名和密碼來辨別身份。

1.2 授權(quán)（Authorization）

授權(quán)表示你能干什么。系統(tǒng)如何控制一個用戶能看到哪些數(shù)據(jù)和操作哪些功能，也就是具有哪些權(quán)限。

1.3 憑證（Credential）

表示你如何證明你的身份。系統(tǒng)如何保證它與用戶之間的承諾是雙方當時真實意圖的體現(xiàn)，是準確、完整和不可抵賴的。

接下來我們看下使用 JWT 作為憑證完成認證的原理。

認證的原理

在如下的認證時序圖中，有以下幾種角色：

• ?客戶端：表示 APP 端或 PC 端的前端頁面。
• 網(wǎng)關(guān)：表示 Spring Cloud Gateway 網(wǎng)關(guān)服務，這里。
• 認證服務：用來接收客戶的登錄請求、登出請求、刷新令牌的操作。
• 業(yè)務服務：和系統(tǒng)業(yè)務相關(guān)的微服務。

認證和校驗身份的流程如下所示：

認證和校驗身份流程

• ① 用戶登錄：客戶端在登錄頁面輸入用戶名和密碼，提交表單，調(diào)用登錄接口。
• ② 轉(zhuǎn)發(fā)請求：這里會先將登錄請求發(fā)送到網(wǎng)關(guān)服務 passjava-gateway，網(wǎng)關(guān)對于登錄請求會直接轉(zhuǎn)發(fā)到認證服務 passjava-auth。（網(wǎng)關(guān)對登錄請求不做 token 校驗，這個可以配置不校驗哪些請求 URL）
• ③ 認證：認證服務會將請求參數(shù)中的用戶名+密碼和數(shù)據(jù)庫中的用戶進行比對，如果完全匹配，則認證通過。
• ④ 生成令牌：生成兩個令牌：access_token 和 refresh_token（刷新令牌），刷新令牌我們后面再說，這里其實也可以只用生成一個令牌 access_token。令牌里面會包含用戶的身份信息，如果要做權(quán)限管控，還需要在 token 里面包含用戶的權(quán)限信息，權(quán)限這一塊不在本篇展開，會放到下一篇中進行講解。
• ⑤ 客戶端緩存 token：客戶端拿到兩個 token 緩存到 cookie 中或者 LocalStorage 中。
• ⑥ 攜帶 token 發(fā)起請求：客戶端下次想調(diào)用業(yè)務服務時，將 access_token 放到請求的 header 中。
• ⑦ 網(wǎng)關(guān)校驗 token：請求還是先到網(wǎng)關(guān)服務，然后由它校驗 access_token 是否合法。如果 access_token 未過期，且能正確解析出來，就說明是合法的 access_token。
• ⑧ 攜帶用戶身份信息轉(zhuǎn)發(fā)請求：網(wǎng)關(guān)將 access_token 中攜帶的用戶的 user_id 放到請求的 header 中，轉(zhuǎn)發(fā)給真正的業(yè)務服務。
• ⑨ 處理業(yè)務邏輯：業(yè)務服務從 header 中拿到用戶的 user_id，然后處理業(yè)務邏輯，處理完后將結(jié)果原路返回給客戶端。
• 接下來我們看下項目的整體架構(gòu)。

項目整體結(jié)構(gòu)

Github 項目地址：https://github.com/Jackson0714/PassJava-Platform

Gitee 項目地址：https://toscode.gitee.com/jayh2018/PassJava-Platform

• 認證服務：passjava-auth
• 網(wǎng)關(guān)服務：passjava-gateway
• JWT 公共項目：passjava-jwt，認證服務和網(wǎng)關(guān)服務都會引用這個公共項目。
• 業(yè)務服務：passjava-member，會員服務作為本次案例的業(yè)務服務。
• Nacos 注冊配置中心

PassJava-Platform 框架

認證服務：passjava-auth

passjava-auth 服務

核心類就是 JwtAuthController 類，里面有登錄接口和刷新令牌的接口。

網(wǎng)關(guān)服務：passjava-gateway

passjava-gateway 服務

核心類就是 JwtAuthCheckFilter 全局過濾器。

如果不需要在服務端保存刷新令牌，可以不需要 redis 配置。

JWT 公共項目

passjava-jwt 服務

核心類就是 PassJavaJWTTokenUtil 工具類。認證服務引入 JWT 項目后用來生成 token，網(wǎng)關(guān)服務引入 JWT 項目后用來校驗 token 合法性。

業(yè)務服務

這里我選擇了會員微服務作為本次演示的業(yè)務微服務。

它從網(wǎng)關(guān)轉(zhuǎn)發(fā)的請求 Header 中拿到 userId， 根據(jù) userId 查詢 member 信息。

passjava-member 服務

核心文件是 MemberController 類、MemberEntity實體類、MemberService服務類、MemberDao 類和 mapper 文件。

啟動的服務

Nacos 注冊配置中心

首先啟動 Nacos 服務。和 PassJava 項目配套使用的 Nacos 工具已經(jīng)上傳到網(wǎng)盤，下載后直接運行啟動腳本就可以將 Nacos 在本地啟動。

啟動教程：

www.passjava.cn/#/01.項目簡介/7.本地部署項目Mac版

網(wǎng)關(guān)、會員、認證服務

啟動以下三個微服務，分別為網(wǎng)關(guān)、會員、認證服務。

檢查下 nacos 注冊中心上是否注冊了這三個服務：可以看到確實有上面的三個微服務。

如何做登錄認證

登錄認證就是校驗下用戶提交的賬戶名和密碼與本地數(shù)據(jù)庫中的是否完全匹配，如果匹配，就認證通過。就是下方這個流程的 1、2、3 步。

第一步：提交用戶名和密碼

這里用 Postman 工具模擬前端發(fā)起登錄請求，請求的 URL 如下：

http://localhost:8060/api/auth/login

請求是向網(wǎng)關(guān)服務 passjava-gateway 發(fā)起的，所以可以看到上面的 URL 中 localhost 和 8060 是網(wǎng)關(guān)的 host 和 port。

然后 API 地址為 /api/auth/login，這個地址經(jīng)過網(wǎng)關(guān)的路由匹配后會轉(zhuǎn)發(fā)到 passjava-auth 服務的登錄 API。

http://localhost:10001/auth/login

關(guān)于網(wǎng)關(guān)轉(zhuǎn)發(fā)的原理可以參考這篇：深入理解 Spring Cloud Gateway 的原理

請求參數(shù)如下：

{
    "userId": "wukong",
    "password": "123456"
}

賬號和密碼都是密文的，轉(zhuǎn)發(fā)到認證服務后，會根據(jù) userId 查詢出系統(tǒng)用戶，然后將 password 參數(shù)加密后對比系統(tǒng)用戶的密碼。

所以為了讓用戶登錄成功，還需要在數(shù)據(jù)庫插入一條系統(tǒng)用戶，用戶 id 為 wukong，密碼是對 123456 加密后的密碼。

在線加密工具地址：

https://www.bejson.com/encrypt/bcrpyt_encode/

第二步：轉(zhuǎn)發(fā)登錄請求

轉(zhuǎn)發(fā)登錄請求是網(wǎng)關(guān)服務做的，所以我們來看下做了哪些事情。

在 Gateway 項目的 application-routers.yml 中配置路由規(guī)則：

spring:
  cloud:
    gateway:
      routes:
        - id: route_auth # 認證微服務路由規(guī)則
          uri: lb://passjava-auth # 負載均衡，將請求轉(zhuǎn)發(fā)到注冊中心注冊的 passjava-auth 服務
          predicates: # 斷言
            - Path=/api/auth/** # 如果前端請求路徑包含 api/auth，則應用這條路由規(guī)則
          filters: #過濾器
            - RewritePath=/api/(?<segment>.*),/$\{segment} # 將跳轉(zhuǎn)路徑中包含的api替換成空

在 application.properties 引入 application-routers.yml

spring:
  profiles:
    include: routers, jwt

第三步：驗證用戶賬號和密碼

這一步是認證服務的登錄 API 里面做的。在 AuthController 中定義 login 接口，核心步驟就是查找系統(tǒng)用戶和比對密碼。

登錄 API

用戶名和密碼匹配成功后，就會生成 JWT 令牌。

如何生成令牌

生成令牌就是通過工具類 PassJavaJwtTokenUtil 生成 JWT Token，也就是流程圖中的第四步。

流程圖-生成 JWT 令牌

生成令牌的核心代碼如下：

生成 JWT 的核心代碼

使用這個工具類的前提是我們需要先引入 jjwt 依賴。這個在 passjava-jwt 項目的 pom 文件中引入。

引入 jjwt 依賴

用 Postman 工具調(diào)用后，可以看到生成的令牌如下：

生成令牌

用 base64 解碼后，可以看到 token 中的 PAYLOAD 里面包含了用戶 id 和用戶名。

生成 JWT 的加密密鑰一般都是寫到配置文件中。這里我是配置在 passjava-jwt 項目的 application-jwt.yml 配置文件中的。

JWT 配置項

然后認證服務就會將 JWT 令牌返回給客戶端了。當客戶端想要查詢這個 userId 對應的會員信息時，就可以在請求的 Header 中帶上 JWT 令牌。

如何攜帶 JWT 發(fā)送請求

客戶端（瀏覽器或 APP）拿到 JWT 后，可以將 JWT 存放在瀏覽器的 Cookie 或 LocalStorage（本地存儲） 或者內(nèi)存中。

發(fā)送請求時在請求 Header 的 Authorization 字段中設置 JWT，這個字段其實可以自定義，但是我建議用 Authorization，因為這是一種業(yè)界標準。

另外告訴大家一個小技巧，在 Postman 工具中有個地方專門配置 Authorization，然后自動加到 Header 中，不用自己手動加 Header。

還有一個點需要注意，這里配置的 Authorization 的認證類型為 Bearer Token。它表示令牌可以是任意字符串格式的令牌。然后會在 Authorization 字段中加上一個前綴 Bearer。所以我們在網(wǎng)關(guān)服務解析 Header 中的 Authorization 時，需要去掉這個前綴 Bearer，代碼如下所示：

去掉 Bearer 前綴

網(wǎng)關(guān)如何驗證 JWT 和轉(zhuǎn)發(fā)請求

網(wǎng)關(guān)驗證 Token和轉(zhuǎn)發(fā)請求

網(wǎng)關(guān)接收到前端發(fā)起的業(yè)務請求后，會先驗證請求的 Header 中是否攜帶 Authorization 字段，以及里面的 Token 是否合法。然后解析 Token 中的 userId 和 username，放到 header 中再進行轉(zhuǎn)發(fā)，也就是流程圖中的第七步和第八步。

網(wǎng)關(guān)是通過多個??過濾器 Filter??對請求進行串行攔截處理的，所以我們可以自定義一個全局過濾器，對所有請求進行校驗，當然對于一些特殊請求比如登錄請求就不需要校驗了，因為調(diào)用登錄請求的時候還沒有生成 Token。

網(wǎng)關(guān)的全局過濾器 JwtAuthCheckFilter 的核心代碼如下所示：

網(wǎng)關(guān)的全局過濾器 JwtAuthCheckFilter

會員服務處理業(yè)務邏輯

會員服務接收到網(wǎng)關(guān)轉(zhuǎn)發(fā)的請求后，就從 Header 中拿到用戶身份信息，然后通過 userId 獲取會員信息。

注意：有的時候業(yè)務邏輯并不需要身份信息，更多的時候是需要檢驗用戶的操作權(quán)限是否足夠。其實 Token 里面也是可以攜帶權(quán)限信息的，不過這是下一篇講解授權(quán)的部分。

獲取 userId 的方式其實可以通過加一個??攔截器??，由攔截器將 Header 中的 userId 和 username 放到線程中，后續(xù)的 controller，service，dao 類都可以從線程里面拿到 userId 和 username，不用通過傳參的方式。

獲取 userId 的方式：

• 方式一：從 request 的 Header 中拿到 userId。代碼簡單，但是如果其他地方也要用到 userId，則需要通過方法傳參的方式傳遞 userId。
• 方式二：從線程變量里面拿到 userId。代碼復雜，使用簡單。好處是所有地方統(tǒng)一從一個地方獲取。

Request 中獲取 userId 方式

代碼示例如下：

下面介紹如何使用攔截器方式將 userId 存入線程變量的方式。

攔截器方式

在 passjava-common 模塊中新增一個攔截器，獲取請求頭中的身份信息，加入到線程變量中。文件名為 HeaderInterceptor。

將攔截器注冊到 WebMvcConfigurer。文件名為 WebMvcConfig.java。

配置文件中需要定義一個配置項：

文件名；org.springframework.boot.autoconfigure.AutoConfiguration.imports
配置項：com.jackson0714.passjava.common.config.WebMvcConfig

然后 passjava-member 服務引入這個攔截器配置。

@Import({WebMvcConfig.class})

通過上面兩種方式中的任意一種拿到 userId 后，通過 userId 查詢會員的詳情。這里需要注意的是這個 user 既是系統(tǒng)用戶也是系統(tǒng)中的會員。關(guān)于查詢會員的數(shù)據(jù)庫操作就不在此展開了。

執(zhí)行結(jié)果如下圖所示：

如何刷新令牌

還有一個內(nèi)容是關(guān)于如何刷新令牌的。當認證服務返回給客戶端的 JWT 也就是 access_token 過期后，客戶端是通過發(fā)送登錄請求重新拿到 access_token 嗎？

這種重新登錄的操作如果很頻繁（因 JWT 過期時間較短），對于用戶來說體驗就很差了。客戶端需要跳轉(zhuǎn)到登錄頁面，讓用戶重新提交用戶名和密碼，即使客戶端有記住用戶名和密碼，但是這種跳轉(zhuǎn)到登錄頁的操作會大幅度降低用戶的體驗，甚至導致用戶不想再用第二次。

有沒有一種比較優(yōu)雅的方式讓客戶端重新拿到 access_token 或者說延長 access_token 有效期呢？

我們知道 JWT 生成后是不能篡改里面的內(nèi)容，即使是 JWT 的有效期也不行。所以延長 access_token 有效期的做法并不適合，而且如果長期保持一個 access_token 有效，也是不安全的。

那就只能重新生成 access_token 了。方案其實挺簡單，客戶端拿之前生成的 JWT 調(diào)用后端一個接口，然后后端校驗這個 JWT 是否合法，如果是合法的就重新生成一個新的返回給客戶端?？蛻舳俗孕刑鎿Q掉之前本地保存的 access_token 就可以了。

生成 access_token 和 refresh_token

這里有一個巧妙的設計，就是生成 JWT 時，返回了兩個 JWT token，一個 access_token，一個 refresh_token，這兩個 token 其實都可以用來刷新 token，但是我們把 refresh_token 設置的過期時間稍微長一點，比如兩倍于 access_token，當 access_token 過期后，refresh_token 如果還沒有過期，就可以利用兩者的過期時間差進行重新生成令牌的操作，也就是刷新令牌，這里的刷新指的是客戶端重置本地保存的令牌，以后都用新的令牌。

饑餓模式和懶模式

當然，在 access_token 過期之前，客戶端提前刷新令牌也是可以的，我稱這種提前刷新的模式為??饑餓模式???（單例模式中也有這種叫法），而過期后再刷新令牌的模式我稱之為??懶模式??。兩種模式都可以用，前者需要客戶端定期檢查過期時間，增加了復雜性；后者則會出現(xiàn)短暫的請求失敗的情況，得拿到新的令牌后才會成功。

刷新令牌的操作完全是通過客戶端自己控制的，而且客戶端也不僅限于瀏覽器，還有可能是第三方服務。

一次性

通常情況下，我們會將刷新令牌 refresh_token 設置為只能用一次，來保證刷新令牌的安全性。而這種就需要服務端來緩存刷新令牌了，當用過一次后，就從緩存里面主動剔除掉。但這樣就違背了 JWT 無狀態(tài)的特性，這個完全看業(yè)務需求來決定是否使用這種緩存方式。

如下圖所示，生成令牌時我將刷新令牌緩存到了 Redis 里面。當我用 refresh_token 調(diào)用刷新 API 時，會主動剔除掉這個 key，下次再用相同的 refresh_token 刷新令牌時，因 Redis 中不存在這個 key，就會提示刷新刷新失敗了。

緩存令牌

留兩個小問題：

• 有沒有辦法讓 access_token 主動失效？
• 場景題：如何保證同一個用戶只能登錄一臺設備？

總結(jié)

雖然本篇是講實戰(zhàn)內(nèi)容的，但是里面又涉及了很多原理性內(nèi)容，比如網(wǎng)關(guān)、JWT 的原理。

結(jié)合實戰(zhàn)講解，相信大家對如何使用 Spring Cloud Gateway + JWT 實現(xiàn)登錄認證有了充分的理解。

本篇只講解了認證和憑證，授權(quán)部分還沒有觸及，所以這也是下篇要講解的內(nèi)容，來追更吧~

最后再說一句，別白嫖，點贊轉(zhuǎn)發(fā)下哦~