[[338308]]

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

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

這是為什么呢?

傳統(tǒng)的認證方式

從一個登錄場景說起

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

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

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

早期的 Cookie-Session 認證方式

早期互聯(lián)網(wǎng)以 web 為主，客戶端是瀏覽器 ，所以 Cookie-Session 方式是早期最常用的認證方式，直到現(xiàn)在，一些 web 網(wǎng)站依然用這種方式做認證。

認證過程大致如下：

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

image-20200706173031724

 

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

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

image-20200706173939291

 

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

接下來，問題來了。你訪問了幾個頁面，這時，有個請求經(jīng)過負載均衡，路由到了另外一臺服務器(不是你登錄的那臺)。當后臺接到請求后，要檢查用戶身份信息和權限，于是接口開始從從 Session 中獲取用戶信息。但是，這臺服務器不是當時登錄的那臺，并沒存你的 Session ，這樣后臺服務就認為你是一個非登錄的用戶，也就不能給你返回數(shù)據(jù)了。

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

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

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

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

Cookie-Session 改造版

由于傳統(tǒng)的 Cookie-Session 認證存在諸多問題，那可以把上面的方案改造一下。1、改造 Cookie 既然 Cookie 不能在 APP 等非瀏覽器中使用，那就不用 cookie 做客戶端存儲，改用其他方式。改成什么呢?web 中可以使用 local storage，APP 中使用客戶端數(shù)據(jù)庫，這樣既能這樣就實現(xiàn)了跨域，并且避免了 CSRF 。

2、服務端也不存 Session 了，把 Session 信息拿出來存到 Redis 等內存數(shù)據(jù)庫中，這樣即提高了速度，又避免了 Session 同步問題;

經(jīng)過改造之后變成了如下的認證過程：

• 用戶輸入用戶名、密碼或者用短信驗證碼方式登錄系統(tǒng);
• 服務端經(jīng)過驗證，將認證信息構造好的數(shù)據(jù)結構存儲到 Redis 中，并將 key 值返回給客戶端;
• 客戶端拿到返回的 key，存儲到 local storage 或本地數(shù)據(jù)庫;
• 下次客戶端再次請求，把 key 值附加到 header 或者 請求體中;
• 服務端根據(jù)獲取的 key，到 Redis 中獲取認證信息;

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

首次登錄

 

 

非首次登錄

 

經(jīng)過一頓猛如虎的改造，解決了傳統(tǒng) Cookie-Session 方式存在的問題。這種改造需要開發(fā)者在項目中自行完成。改造起來肯定是費時費力的，而且還有可能存在漏洞。

JWT 出場

這時，JWT 就可以上場了，JWT 就是一種Cookie-Session改造版的具體實現(xiàn)，讓你省去自己造輪子的時間，JWT 還有個好處，那就是你可以不用在服務端存儲認證信息(比如 token)，完全由客戶端提供，服務端只要根據(jù) JWT 自身提供的解密算法就可以驗證用戶合法性，而且這個過程是安全的。

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

JWT 數(shù)據(jù)結構

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

997EDE1C-5689-4C3F-98E8-25C25BBEC3FC

 

頭部

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

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

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

載荷

用來存儲服務器需要的數(shù)據(jù)，比如用戶信息，例如姓名、性別、年齡等，要注意的是重要的機密信息最好不要放到這里，比如密碼等。

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

另外，JWT 還規(guī)定了 7 個字段供開發(fā)者選用。

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

這部分信息也是要用 Base64 編碼的。

簽名

簽名有一個計算公式。

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

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

使用方式

了解了 JWT 的結構和算法后，那怎么使用呢?假設我這兒有個網(wǎng)站。

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

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

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

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

 

 

怎么保證安全性

的保證安全性的關鍵就是 HMACSHA256 或者與它同類型的加密算法，因為加密過程是不可逆的，所以不能根據(jù)傳到前端的 JWT 傳反解到密鑰信息。

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

別人拿到完整 JWT 還安全嗎

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

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

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

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

 

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

一個問題

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

常用的 JWT 庫JWT 官網(wǎng)列出了各種語言對應的庫，其中 Java 的如下幾個。

image-20200817112359199

 

以 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、登錄成功后，再次發(fā)起請求的時候將 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 方法創(chuàng)建的 JWT 串可以通過驗證。

 

而如果我將 JWT 串中的載荷部分，兩個點號中間的部分修改一下，然后再調用 verify 方法驗證，會出現(xiàn) JWTVerificationException 異常，不能通過驗證。

本文轉載自微信公眾號「古時的風箏」，可以通過以下二維碼關注。轉載本文請聯(lián)系古時的風箏 公眾號。