『JWT』，你必須了解的認證登錄方案

我是風箏，公眾號「古時的風箏」，一個兼具深度與廣度的程式員鼓勵師，一個本打算寫詩卻寫起了代碼的田園碼農！
文章會收錄在 JavaNewBee 中，更有 Java 后端知識圖譜，從小白到大牛要走的路都在里面，

JWT 全稱是 JSON Web Token，是目前非常流行的跨域認證解決方案，在單點登錄場景中經常使用到，

有些人覺得它非常好用，用了它之后就不用在服務端借助 redis 實作認證程序了，但是，還有一部分人認為它生來就有缺陷，根本不能用，

這是為什么呢？

傳統的認證方式

從一個登錄場景說起

你平時用過那么多網站和 APP，其中有很多都是需要登錄的吧，那咱們就選一個場景出來說說，

以一個電商系統為例，如果你想要下單，首先需要注冊一個賬號，擁有了賬號之后，需要輸入用戶名（比如手機號或郵箱）、密碼完成登錄程序，之后你在一段時間內再次進入系統，是不需要輸入用戶名和密碼的，只有在連續長時間不登錄的情況下（例如一個月沒登錄過）訪問系統，才需要再次輸入用戶名和密碼，

對于那些使用頻率很高的網站或應用，通常是很長時間都不需要輸入密碼的，以至于你在換了一臺電腦或者一部手機之后，一些經常使用的網站或 APP 的密碼都不記得了，

早期的 Cookie-Session 認證方式

早期互聯網以 web 為主，客戶端是瀏覽器 ，所以 Cookie-Session 方式是早期最常用的認證方式，直到現在，一些 web 網站依然用這種方式做認證，

認證程序大致如下：

1. 用戶輸入用戶名、密碼或者用短信驗證碼方式登錄系統；
2. 服務端驗證后，創建一個 Session 資訊，并且將 SessionID 存到 cookie，發送回瀏覽器；
3. 下次客戶端再發起請求，自動帶上 cookie 資訊，服務端通過 cookie 獲取 Session 資訊進行校驗；

但是為什么說它是傳統的認證方式，因為現在人手一部智能手機，很多人都不用電腦，平時都是使用手機上的各種 APP，比如淘寶、拼多多等，
在這種潮流之下，傳統的 Cookie-Session 就遇到了一些問題：
1、首先，Cookie-Session 只能在 web 場景下使用，如果是 APP 呢，APP 可沒有地方存 cookie，
現在的產品基本上都同時提供 web 端和 APP 兩種使用方式，有點產品甚至只有 APP，

2、退一萬步說，你做的產品只支持 web，也要考慮跨域問題， 但Cookie 是不能跨域的，
拿天貓商城來說，當你進入天貓商城后，會看到頂部有天貓超市、天貓國際、天貓會員這些選單，而點擊這些選單都會進入不同的域名，不同的域名下的 cookie 都是不一樣的，你在 A 域名下是沒辦法拿到 B 域名的 cookie 的，即使是子域也不行，

3、如果是分布式服務，需要考慮 Session 同步問題，
現在的互聯網網站和 APP 基本上都是分布式部署，也就是服務端不止一臺機器，當某個用戶在頁面上進行登錄操作后，這個登錄動作必定是請求到了其中某一臺服務器上，你的身份資訊得保存下來吧，傳統方式就是存 Session，

接下來，問題來了，你訪問了幾個頁面，這時，有個請求經過負載均衡，路由到了另外一臺服務器（不是你登錄的那臺），當后臺接到請求后，要檢查用戶身份資訊和權限，于是介面開始從從 Session 中獲取用戶資訊，但是，這臺服務器不是當時登錄的那臺，并沒存你的 Session ，這樣后臺服務就認為你是一個非登錄的用戶，也就不能給你回傳資料了，

所以，為了避免這種情況的發生，就要做 Session 同步，一臺服務器接收到登錄請求后，在當前服務器保存 Session 后，也要向其他幾個服務器同步，

4、cookie 存在 CSRF（跨站請求偽造）的風險， 跨站請求偽造，是一種挾制用戶在當前已登錄的Web應用程式上執行非本意的操作的攻擊方法，CSRF 利用的是網站對用戶網頁瀏覽器的信任，簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站并運行一些操作（比如購買商品），由于瀏覽器曾經認證過，所以被訪問的網站會認為是真正的用戶發起的操作，
比如說我是一個黑客，我發現你經常訪問的一個技術網站存在 CSRF 漏洞，發布文章支持 html 格式，進而我在 html 中加入一些危險內容，例如

 <img src=https://www.cnblogs.com/fengzheng/p/"http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

假設 src 指向的地址是一個你平時用的購物網站的付款地址（當然只是舉例，真正的攻擊可沒這么簡單），如果你之前登錄過并且標識你身份資訊的 cookie 已經保存下來了，當你刷到我發布的這篇文章的時候，img 標簽一加載，這個 CSRF 攻擊就會起作用，在你不知情的情況下向這個網站付款了，

Cookie-Session 改造版

由于傳統的 Cookie-Session 認證存在諸多問題，那可以把上面的方案改造一下，
1、改造 Cookie 既然 Cookie 不能在 APP 等非瀏覽器中使用，那就不用 cookie 做客戶端存盤，改用其他方式，
改成什么呢？
web 中可以使用 local storage，APP 中使用客戶端資料庫，這樣既能這樣就實作了跨域，并且避免了 CSRF ，

2、服務端也不存 Session 了，把 Session 資訊拿出來存到 Redis 等記憶體資料庫中，這樣即提高了速度，又避免了 Session 同步問題；

經過改造之后變成了如下的認證程序：

1. 用戶輸入用戶名、密碼或者用短信驗證碼方式登錄系統；
2. 服務端經過驗證，將認證資訊構造好的資料結構存盤到 Redis 中，并將 key 值回傳給客戶端；
3. 客戶端拿到回傳的 key，存盤到 local storage 或本地資料庫；
4. 下次客戶端再次請求，把 key 值附加到 header 或者 請求體中；
5. 服務端根據獲取的 key，到 Redis 中獲取認證資訊；

下面兩張圖分別演示了首次登錄和非首次登錄的程序，

經過一頓猛如虎的改造，解決了傳統 Cookie-Session 方式存在的問題，這種改造需要開發者在專案中自行完成，改造起來肯定是費時費力的，而且還有可能存在漏洞，

JWT 出場

這時，JWT 就可以上場了，JWT 就是一種Cookie-Session改造版的具體實作，讓你省去自己造輪子的時間，JWT 還有個好處，那就是你可以不用在服務端存盤認證資訊（比如 token），完全由客戶端提供，服務端只要根據 JWT 自身提供的解密演算法就可以驗證用戶合法性，而且這個程序是安全的，

如果你是剛接觸 JWT，最有疑問的一點可能就是： JWT 為什么可以完全依靠客戶端(比如瀏覽器端)就能實作認證功能，認證資訊全都存在客戶端，怎么保證安全性？

JWT 資料結構

JWT 最后的形式就是個字串，它由頭部、載荷與簽名這三部分組成，中間以「.」分隔，像下面這樣：

頭部

頭部以 JSON 格式表示，用于指明令牌型別和加密演算法，形式如下，表示使用 JWT 格式，加密演算法采用 HS256，這是最常用的演算法，除此之外還有很多其他的，

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

對應上圖的紅色 header 部分，需要 Base64 編碼，

載荷

用來存盤服務器需要的資料，比如用戶資訊，例如姓名、性別、年齡等，要注意的是重要的機密資訊最好不要放到這里，比如密碼等，

{
  "name": "古時的風箏",
  "introduce": "英俊瀟灑"
}

另外，JWT 還規定了 7 個欄位供開發者選用，

• iss (issuer)：簽發人
• exp (expiration time)：過期時間
• sub (subject)：主題
• aud (audience)：受眾
• nbf (Not Before)：生效時間
• iat (Issued At)：簽發時間
• jti (JWT ID)：編號

這部分資訊也是要用 Base64 編碼的，

簽名

簽名有一個計算公式，

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

使用HMACSHA256演算法計算得出，這個方法有兩個引數，前一個引數是 （base64 編碼的頭部 + base64 編碼的載荷）用點號相連，后一個引數是自定義的字串密鑰，密鑰不要暴露在客戶端，近應該服務器知道，

使用方式

了解了 JWT 的結構和演算法后，那怎么使用呢？假設我這兒有個網站，

1、在用戶登錄網站的時候，需要輸入用戶名、密碼或者短信驗證的方式登錄，登錄請求到達服務端的時候，服務端對賬號、密碼進行驗證，然后計算出 JWT 字串，回傳給客戶端，

2、客戶端拿到這個 JWT 字串后，存盤到 cookie 或者 瀏覽器的 LocalStorage 中，

3、再次發送請求，比如請求用戶設定頁面的時候，在 HTTP 請求頭中加入 JWT 字串，或者直接放到請求主體中，

4、服務端拿到這串 JWT 字串后，使用 base64的頭部和 base64 的載荷部分，通過HMACSHA256演算法計算簽名部分，比較計算結果和傳來的簽名部分是否一致，如果一致，說明此次請求沒有問題，如果不一致，說明請求過期或者是非法請求，

怎么保證安全性的

保證安全性的關鍵就是 HMACSHA256 或者與它同型別的加密演算法，因為加密程序是不可逆的，所以不能根據傳到前端的 JWT 傳反解到密鑰資訊，

另外，不同的頭部和載荷加密之后得到的簽名都是不同的，所以，如果有人改了載荷部分的資訊，那最后加密出的結果肯定就和改之前的不一樣的，所以，最后驗證的結果就是不合法的請求，

別人拿到完整 JWT 還安全嗎

假設載荷部分存盤了權限級別相關的欄位，強盜拿到 JWT 串后想要修改為更高權限的級別，上面剛說了，這種情況下是肯定不會得逞的，因為加密出來的簽名會不一樣，服務器可能很容易的判別出來，

那如果強盜拿到后不做更改，直接用呢，那就沒有辦法了，為了更大程度上防止被強盜盜取，應該使用 HTTPS 協議而不是 HTTP 協議，這樣可以有效的防止一些中間劫持攻擊行為，

有同學就要說了，這一點也不安全啊，拿到 JWT 串就可以輕松模擬請求了，確實是這樣，但是前提是你怎么樣能拿到，除了上面說的中間劫持外，還有什么辦法嗎？

除非強盜直接拿了你的電腦，那這樣的話，對不起，不光 JWT 不安全了，其他任何網站，任何認證方式都不安全，

雖然這樣的情況很少，但是在使用 JWT 的時候仍然要注意合理的設定過期時間，不要太長，

一個問題

JWT 有個問題，導致很多開發團隊放棄使用它，那就是一旦頒發一個 JWT 令牌，服務端就沒辦法廢棄掉它，除非等到它自身過期，有很多應用默認只允許最新登錄的一個客戶端正常使用，不允許多端登錄，JWT 就沒辦法做到，因為頒發了新令牌，但是老的令牌在過期前仍然可用，這種情況下，就需要服務端增加相應的邏輯，

常用的 JWT 庫

JWT 官網列出了各種語言對應的庫，其中 Java 的如下幾個，

以 java-jwt為例，

1、引入對應的 Maven 包，

<dependency>
    <groupId>com.auth0</groupId>
    <artifactId>java-jwt</artifactId>
    <version>3.10.3</version>
</dependency>

2、在登錄時，呼叫 create 方法得到一個令牌，并回傳給前端，

public static String create(){
  try {
    Algorithm algorithm = Algorithm.HMAC256("secret");
    String token = JWT.create()
      .withIssuer("auth0")
      .withSubject("subject")
      .withClaim("name","古時的風箏")
      .withClaim("introduce","英俊瀟灑")
      .sign(algorithm);
    System.out.println(token);
    return token;
  } catch (JWTCreationException exception){
    //Invalid Signing configuration / Couldn't convert Claims.
    throw exception;
  }
}

3、登錄成功后，再次發起請求的時候將 token 放到 header 或者請求體中，服務端對 token 進行驗證，

public static Boolean verify(String token){
  try {
    Algorithm algorithm = Algorithm.HMAC256("secret");
    JWTVerifier verifier = JWT.require(algorithm)
      .withIssuer("auth0")
      .build(); //Reusable verifier instance
    DecodedJWT jwt = verifier.verify(token);
    String payload = jwt.getPayload();
    String name = jwt.getClaim("name").asString();
    String introduce = jwt.getClaim("introduce").asString();
    System.out.println(payload);
    System.out.println(name);
    System.out.println(introduce);
    return true;
  } catch (JWTVerificationException exception){
    //Invalid signature/claims
    return false;
  }
}

4、用 create 方法生成 token，并用 verify 方法驗證一下，

public static void main(String[] args){
  String token = create();
  Boolean result = verify(token);
  System.out.println(result);
}

得到下面的結果

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0.ooQ1K_XyljjHf34Nv5iJvg1MQgVe6jlphxv4eeFt8pA
eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0
古時的風箏
英俊瀟灑
true

使用 create 方法創建的 JWT 串可以通過驗證，

而如果我將 JWT 串中的載荷部分，兩個點號中間的部分修改一下，然后再呼叫 verify 方法驗證，會出現 JWTVerificationException 例外，不能通過驗證，

這位英俊瀟灑的少年，如果覺得還不錯的話，給個推薦可好！

公眾號「古時的風箏」，Java 開發者，全堆疊工程師，bug 殺手，擅長解決問題，
一個兼具深度與廣度的程式員鼓勵師，本打算寫詩卻寫起了代碼的田園碼農！堅持原創干貨輸出，你可選擇現在就關注我，或者看看歷史文章再關注也不遲，長按二維碼關注，跟我一起變優秀！

標籤：Java

上一篇：Istio 1.4 更新了 | 感覺學不完

下一篇：從零搭建Spring Boot腳手架（6）：整合Redis作為快取