蝦皮二面：什么是 JWT? 如何基于 JWT 進(jìn)行身份驗證？

你好，分享一下群友面試蝦皮遇到的關(guān)于 JWT 的面試真題。

相關(guān)面試題如下：

• 什么是 JWT?為什么要用 JWT？
• JWT 由哪些部分組成？
• 如何基于 JWT 進(jìn)行身份驗證？
• JWT 如何防止 Token 被篡改？
• 如何加強(qiáng) JWT 的安全性？
• 如何讓 Token 失效？
• ......

什么是 JWT?

JWT （JSON Web Token） 是目前最流行的跨域認(rèn)證解決方案，是一種基于 Token 的認(rèn)證授權(quán)機(jī)制。從 JWT 的全稱可以看出，JWT 本身也是 Token，一種規(guī)范化之后的 JSON 結(jié)構(gòu)的 Token。

Token 自身包含了身份驗證所需要的所有信息，因此，我們的服務(wù)器不需要存儲 Session 信息。這顯然增加了系統(tǒng)的可用性和伸縮性，大大減輕了服務(wù)端的壓力。

可以看出，JWT 更符合設(shè)計 RESTful API 時的「Stateless（無狀態(tài)）」原則。

并且， 使用 Token 認(rèn)證可以有效避免 CSRF 攻擊，因為 Token 一般是存在在 localStorage 中，使用 JWT 進(jìn)行身份驗證的過程中是不會涉及到 Cookie 的。

我在JWT 優(yōu)缺點分析^[1]這篇文章中有詳細(xì)介紹到使用 JWT 做身份認(rèn)證的優(yōu)勢和劣勢。

下面是RFC 7519^[2]對 JWT 做的較為正式的定義。

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. ——JSON Web Token (JWT)^[3]

JWT 由哪些部分組成？

JWT 本質(zhì)上就是一組字串，通過（.）切分成三個為 Base64 編碼的部分：

• Header: 描述 JWT 的元數(shù)據(jù)，定義了生成簽名的算法以及Token的類型。
• Payload: 用來存放實際需要傳遞的數(shù)據(jù)
• Signature（簽名）：服務(wù)器通過 Payload、Header 和一個密鑰(Secret)使用 Header 里面指定的簽名算法（默認(rèn)是 HMAC SHA256）生成。

JWT 通常是這樣的：xxxxx.yyyyy.zzzzz。

示例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

你可以在jwt.io^[4]這個網(wǎng)站上對其 JWT 進(jìn)行解碼，解碼之后得到的就是 Header、Payload、Signature 這三部分。

Header 和 Payload 都是 JSON 格式的數(shù)據(jù)，Signature 由 Payload、Header 和 Secret(密鑰)通過特定的計算公式和加密算法得到。

Header

Header 通常由兩部分組成：

• typ（Type）：令牌類型，也就是 JWT。
• alg（Algorithm） ：簽名算法，比如 HS256。

示例：

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

JSON 形式的 Header 被轉(zhuǎn)換成 Base64 編碼，成為 JWT 的第一部分。

Payload

Payload 也是 JSON 格式數(shù)據(jù)，其中包含了 Claims(聲明，包含 JWT 的相關(guān)信息)。

Claims 分為三種類型：

• Registered Claims（注冊聲明）：預(yù)定義的一些聲明，建議使用，但不是強(qiáng)制性的。
• Public Claims（公有聲明）：JWT 簽發(fā)方可以自定義的聲明，但是為了避免沖突，應(yīng)該在IANA JSON Web Token Registry^[5]中定義它們。
• Private Claims（私有聲明）：JWT 簽發(fā)方因為項目需要而自定義的聲明，更符合實際項目場景使用。

下面是一些常見的注冊聲明：

• iss（issuer）：JWT 簽發(fā)方。
• iat（issued at time）：JWT 簽發(fā)時間。
• sub（subject）：JWT 主題。
• aud（audience）：JWT 接收方。
• exp（expiration time）：JWT 的過期時間。
• nbf（not before time）：JWT 生效時間，早于該定義的時間的 JWT 不能被接受處理。
• jti（JWT ID）：JWT 唯一標(biāo)識。

示例：

{
??"uid":?"ff1212f5-d8d1-4496-bf41-d2dda73de19a",
??"sub":?"1234567890",
??"name":?"John?Doe",
??"exp":?15323232,
??"iat":?1516239022,
??"scope":?["admin",?"user"]
}

Payload 部分默認(rèn)是不加密的，一定不要將隱私信息存放在 Payload 當(dāng)中！?。?/span>

JSON 形式的 Payload 被轉(zhuǎn)換成 Base64 編碼，成為 JWT 的第二部分。

Signature

Signature 部分是對前兩部分的簽名，作用是防止 Token（主要是 payload） 被篡改。

這個簽名的生成需要用到：

• Header + Payload。
• 存放在服務(wù)端的密鑰(一定不要泄露出去)。
• 簽名算法。

簽名的計算公式如下：

HMACSHA256(
??base64UrlEncode(header)?+?"."?+
??base64UrlEncode(payload),
??secret)

算出簽名以后，把 Header、Payload、Signature 三個部分拼成一個字符串，每個部分之間用"點"（.）分隔，成為 JWT 的第三部分。

如何基于 JWT 進(jìn)行身份驗證？

在基于 Token 進(jìn)行身份驗證的的應(yīng)用程序中，服務(wù)器通過 Payload、Header 和Secret(密鑰)創(chuàng)建Token（令牌）并將Token發(fā)送給客戶端?？蛻舳私邮盏?code style="border-radius: 4px;font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;letter-spacing: 0.07em;font-size: 13px;color: rgb(155, 110, 35);background-color: rgb(255, 249, 227);padding: 3px;">Token之后，會將其保存在 Cookie 或者 localStorage 里面，以后客戶端發(fā)出的所有請求都會攜帶這個令牌。

簡化后的步驟如下：

1. 用戶向服務(wù)器發(fā)送用戶名、密碼以及驗證碼用于登陸系統(tǒng)。
2. 如果用戶用戶名、密碼以及驗證碼校驗正確的話，服務(wù)端會返回已經(jīng)簽名的Token。
3. 用戶以后每次向后端發(fā)請求都在 Header 中帶上這個Token。
4. 服務(wù)端檢查Token并從中獲取用戶相關(guān)信息。

兩點建議：

1. 建議將Token存放在 localStorage 中，放在 Cookie 中會有 CSRF 風(fēng)險。
2. 請求服務(wù)端并攜帶 Token 的常見做法是將Token放在 HTTP Header 的Authorization字段中（Authorization: Bearer Token）。

spring-security-jwt-guide^[6]就是一個基于 JWT 來做身份認(rèn)證的簡單案例，感興趣的可以看看。

JWT 如何防止 Token 被篡改？

有了簽名之后，即使 Token 被泄露或者解惑，黑客也沒辦法同時篡改 Signature 、Header 、Payload。

這是為什么呢？因為服務(wù)端拿到 Token 之后，會解析出其中包含的 Header、Payload 以及 Signature 。服務(wù)端會根據(jù) Header、Payload、密鑰再次生成一個 Signature。拿新生成的 Signature 和 Token 中的 Signature 作對比，如果一樣就說明 Header 和 Payload 沒有被修改。

不過，如果服務(wù)端的秘鑰也被泄露的話，黑客就可以同時篡改 Signature 、Header 、Payload 了。黑客直接修改了 Header 和 Payload 之后，再重新生成一個 Signature 就可以了。

密鑰一定保管好，一定不要泄露出去。JWT 安全的核心在于簽名，簽名安全的核心在密鑰。

如何加強(qiáng) JWT 的安全性？

1. 使用安全系數(shù)高的加密算法。
2. 使用成熟的開源庫，沒必要造輪子。
3. Token 存放在 localStorage 中而不是 Cookie 中，避免 CSRF 風(fēng)險。
4. 一定不要將隱私信息存放在 Payload 當(dāng)中。
5. 密鑰一定保管好，一定不要泄露出去。JWT 安全的核心在于簽名，簽名安全的核心在密鑰。
6. Payload 要加入exp（JWT 的過期時間），永久有效的 JWT 不合理。并且，JWT 的過期時間不易過長。
7. ......

參考資料