原文連結：/file/2020/08/19/20200819181830_1614.jpg.html 全稱是 JSON Web Token，是目前非常流行的跨域認證解決方案，在單點登入場景中經常使用到。

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

這是為什麼呢？

傳統的認證方式從一個登入場景說起

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

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

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

早期的 Cookie-Session 認證方式

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

認證過程大致如下：

但是為什麼說它是傳統的認證方式，因為現在人手一部智慧手機，很多人都不用電腦，平時都是使用手機上的各種 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="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 同步問題；

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

使用者輸入使用者名稱、密碼或者用簡訊驗證碼方式登入系統；服務端經過驗證，將認證資訊構造好的資料結構儲存到 Redis 中，並將 key 值返回給客戶端；客戶端拿到返回的 key，儲存到 local storage 或本地資料庫；下次客戶端再次請求，把 key 值附加到 header 或者 請求體中；服務端根據獲取的 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_XyljjHf34Nv5iJvg1MQgVe6jlphxv4eeFt8pAeyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0古時的風箏英俊瀟灑true

使用 create 方法建立的 JWT 串可以通過驗證。

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