[[338308]]

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

有些人覺(jué)得它非常好用，用了它之后就不用在服務(wù)端借助 redis 實(shí)現(xiàn)認(rèn)證過(guò)程了，但是，還有一部分人認(rèn)為它生來(lái)就有缺陷，根本不能用。

這是為什么呢?

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

從一個(gè)登錄場(chǎng)景說(shuō)起

你平時(shí)用過(guò)那么多網(wǎng)站和 APP，其中有很多都是需要登錄的吧，那咱們就選一個(gè)場(chǎng)景出來(lái)說(shuō)說(shuō)。

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

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

早期的 Cookie-Session 認(rèn)證方式

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

認(rèn)證過(guò)程大致如下：

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

image-20200706173031724

 

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

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

image-20200706173939291

 

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

接下來(lái)，問(wèn)題來(lái)了。你訪問(wèn)了幾個(gè)頁(yè)面，這時(shí)，有個(gè)請(qǐng)求經(jīng)過(guò)負(fù)載均衡，路由到了另外一臺(tái)服務(wù)器(不是你登錄的那臺(tái))。當(dāng)后臺(tái)接到請(qǐng)求后，要檢查用戶身份信息和權(quán)限，于是接口開(kāi)始從從 Session 中獲取用戶信息。但是，這臺(tái)服務(wù)器不是當(dāng)時(shí)登錄的那臺(tái)，并沒(méi)存你的 Session ，這樣后臺(tái)服務(wù)就認(rèn)為你是一個(gè)非登錄的用戶，也就不能給你返回?cái)?shù)據(jù)了。

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

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

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

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

Cookie-Session 改造版

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

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

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

• 用戶輸入用戶名、密碼或者用短信驗(yàn)證碼方式登錄系統(tǒng);
• 服務(wù)端經(jīng)過(guò)驗(yàn)證，將認(rèn)證信息構(gòu)造好的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)到 Redis 中，并將 key 值返回給客戶端;
• 客戶端拿到返回的 key，存儲(chǔ)到 local storage 或本地?cái)?shù)據(jù)庫(kù);
• 下次客戶端再次請(qǐng)求，把 key 值附加到 header 或者 請(qǐng)求體中;
• 服務(wù)端根據(jù)獲取的 key，到 Redis 中獲取認(rèn)證信息;

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

首次登錄

 

 

非首次登錄

 

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

JWT 出場(chǎng)

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

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

JWT 數(shù)據(jù)結(jié)構(gòu)

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

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

 

頭部

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

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

對(duì)應(yīng)上圖的紅色 header 部分，需要 Base64 編碼。

載荷

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

{ 
  "name": "古時(shí)的風(fēng)箏", 
  "introduce": "英俊瀟灑" 
} 

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

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

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

簽名

簽名有一個(gè)計(jì)算公式。

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

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

使用方式

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

1、在用戶登錄網(wǎng)站的時(shí)候，需要輸入用戶名、密碼或者短信驗(yàn)證的方式登錄，登錄請(qǐng)求到達(dá)服務(wù)端的時(shí)候，服務(wù)端對(duì)賬號(hào)、密碼進(jìn)行驗(yàn)證，然后計(jì)算出 JWT 字符串，返回給客戶端。

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

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

4、服務(wù)端拿到這串 JWT 字符串后，使用 base64的頭部和 base64 的載荷部分，通過(guò)HMACSHA256算法計(jì)算簽名部分，比較計(jì)算結(jié)果和傳來(lái)的簽名部分是否一致，如果一致，說(shuō)明此次請(qǐng)求沒(méi)有問(wèn)題，如果不一致，說(shuō)明請(qǐng)求過(guò)期或者是非法請(qǐng)求。

 

 

怎么保證安全性

的保證安全性的關(guān)鍵就是 HMACSHA256 或者與它同類型的加密算法，因?yàn)榧用苓^(guò)程是不可逆的，所以不能根據(jù)傳到前端的 JWT 傳反解到密鑰信息。

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

別人拿到完整 JWT 還安全嗎

假設(shè)載荷部分存儲(chǔ)了權(quán)限級(jí)別相關(guān)的字段，強(qiáng)盜拿到 JWT 串后想要修改為更高權(quán)限的級(jí)別，上面剛說(shuō)了，這種情況下是肯定不會(huì)得逞的，因?yàn)榧用艹鰜?lái)的簽名會(huì)不一樣，服務(wù)器可能很容易的判別出來(lái)。

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

有同學(xué)就要說(shuō)了，這一點(diǎn)也不安全啊，拿到 JWT 串就可以輕松模擬請(qǐng)求了。確實(shí)是這樣，但是前提是你怎么樣能拿到，除了上面說(shuō)的中間劫持外，還有什么辦法嗎?

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

 

雖然這樣的情況很少，但是在使用 JWT 的時(shí)候仍然要注意合理的設(shè)置過(guò)期時(shí)間，不要太長(zhǎng)。

一個(gè)問(wèn)題

JWT 有個(gè)問(wèn)題，導(dǎo)致很多開(kāi)發(fā)團(tuán)隊(duì)放棄使用它，那就是一旦頒發(fā)一個(gè) JWT 令牌，服務(wù)端就沒(méi)辦法廢棄掉它，除非等到它自身過(guò)期。有很多應(yīng)用默認(rèn)只允許最新登錄的一個(gè)客戶端正常使用，不允許多端登錄，JWT 就沒(méi)辦法做到，因?yàn)轭C發(fā)了新令牌，但是老的令牌在過(guò)期前仍然可用。這種情況下，就需要服務(wù)端增加相應(yīng)的邏輯。

常用的 JWT 庫(kù)JWT 官網(wǎng)列出了各種語(yǔ)言對(duì)應(yīng)的庫(kù)，其中 Java 的如下幾個(gè)。

image-20200817112359199

 

以 java-jwt為例。

1、引入對(duì)應(yīng)的 Maven 包。

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

2、在登錄時(shí)，調(diào)用 create 方法得到一個(gè)令牌，并返回給前端。

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

3、登錄成功后，再次發(fā)起請(qǐng)求的時(shí)候?qū)?token 放到 header 或者請(qǐng)求體中，服務(wù)端對(duì) token 進(jìn)行驗(yàn)證。

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 方法驗(yàn)證一下。

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

得到下面的結(jié)果

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0.ooQ1K_XyljjHf34Nv5iJvg1MQgVe6jlphxv4eeFt8pA 
eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0 
古時(shí)的風(fēng)箏 
英俊瀟灑 
true 

使用 create 方法創(chuàng)建的 JWT 串可以通過(guò)驗(yàn)證。

 

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

本文轉(zhuǎn)載自微信公眾號(hào)「古時(shí)的風(fēng)箏」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系古時(shí)的風(fēng)箏 公眾號(hào)。