JWT認(rèn)證登錄的方法是什么

本文小編為大家詳細(xì)介紹“JWT認(rèn)證登錄的方法是什么”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“JWT認(rèn)證登錄的方法是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來(lái)學(xué)習(xí)新知識(shí)吧。

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

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

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

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

1. 用戶輸入用戶名、密碼或者用短信驗(yàn)證碼方式登錄系統(tǒng)；

2. 服務(wù)端驗(yàn)證后，創(chuàng)建一個(gè) Session 信息，并且將 SessionID 存到 cookie，發(fā)送回瀏覽器；

3. 下次客戶端再發(fā)起請(qǐng)求，自動(dòng)帶上 cookie 信息，服務(wù)端通過 cookie 獲取 Session 信息進(jìn)行校驗(yàn)；

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

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

3、如果是分布式服務(wù)，需要考慮 Session 同步問題。 現(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)，問題來(lái)了。你訪問了幾個(gè)頁(yè)面，這時(shí)，有個(gè)請(qǐng)求經(jīng)過負(fù)載均衡，路由到了另外一臺(tái)服務(wù)器（不是你登錄的那臺(tái)）。當(dāng)后臺(tái)接到請(qǐng)求后，要檢查用戶身份信息和權(quán)限，于是接口開始從從 Session 中獲取用戶信息。但是，這臺(tái)服務(wù)器不是當(dāng)時(shí)登錄的那臺(tá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)單地說，是攻擊者通過一些技術(shù)手段欺騙用戶的瀏覽器去訪問一個(gè)自己曾經(jīng)認(rèn)證過的網(wǎng)站并運(yùn)行一些操作（比如購(gòu)買商品）。由于瀏覽器曾經(jīng)認(rèn)證過，所以被訪問的網(wǎng)站會(huì)認(rèn)為是真正的用戶發(fā)起的操作。 比如說我是一個(gè)黑客，我發(fā)現(xiàn)你經(jīng)常訪問的一個(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)然只是舉例，真正的攻擊可沒這么簡(jiǎn)單），如果你之前登錄過并且標(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)證存在諸多問題，那可以把上面的方案改造一下。 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 同步問題；

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

1. 用戶輸入用戶名、密碼或者用短信驗(yàn)證碼方式登錄系統(tǒng)；

2. 服務(wù)端經(jīng)過驗(yàn)證，將認(rèn)證信息構(gòu)造好的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)到 Redis 中，并將 key 值返回給客戶端；

3. 客戶端拿到返回的 key，存儲(chǔ)到 local storage 或本地?cái)?shù)據(jù)庫(kù)；

4. 下次客戶端再次請(qǐng)求，把 key 值附加到 header 或者 請(qǐng)求體中；

5. 服務(wù)端根據(jù)獲取的 key，到 Redis 中獲取認(rèn)證信息；

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

經(jīng)過一頓猛如虎的改造，解決了傳統(tǒng) Cookie-Session 方式存在的問題。這種改造需要開發(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è)過程是安全的。

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

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

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

頭部

頭部以 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è)字段供開發(fā)者選用。

• iss (issuer)：簽發(fā)人

• exp (expiration time)：過期時(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 的載荷部分，通過HMACSHA256算法計(jì)算簽名部分，比較計(jì)算結(jié)果和傳來(lái)的簽名部分是否一致，如果一致，說明此次請(qǐng)求沒有問題，如果不一致，說明請(qǐng)求過期或者是非法請(qǐng)求。

怎么保證安全性的

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

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

別人拿到完整 JWT 還安全嗎

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

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

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

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

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

一個(gè)問題

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

常用的 JWT 庫(kù)

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

以 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 串可以通過驗(yàn)證。

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

讀到這里，這篇“JWT認(rèn)證登錄的方法是什么”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過才能領(lǐng)會(huì)，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。