JSON Web Tokens (JWT)

JSON Web Token (JWT)（發音為 "jot"）是一種開放標準 (RFC 7519)，定義了一種緊湊且自包含的方式，用於在各方之間作為 JSON 物件安全地傳輸資訊。因為它是數位簽名的，所以此資訊可以被驗證和信任。

在 API 世界中，JWT 是 Access Tokens 和 ID Tokens 最常見的格式。

JWT 的結構

一個 JWT 由點 (.) 分隔的三個部分組成：
Header.Payload.Signature

範例：eyJhbGciOiJIUzI1Ni... .eyJzdWIiOiIxMjM0NTY3ODkw... .SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header (標頭)

描述 Token 如何被簽名。

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

2. Payload (Claims/聲明)

包含資料（聲明）。有標準聲明和自訂聲明。

{
  "sub": "1234567890",   // 主題 (User ID)
  "name": "John Doe",
  "iat": 1516239022,     // 簽發時間
  "exp": 1516242622,     // 過期時間
  "role": "admin"        // 自訂聲明
}

注意：此資料是 Base64Url 編碼的，不是加密的。任何擁有 Token 的人都可以讀取此資料。不要將機密資訊放在這裡。

3. Signature (簽名)

要建立簽名部分，您必須獲取編碼的 Header、編碼的 Payload、一個 Secret (密鑰)，以及 Header 中指定的演算法，並對其進行簽名。

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

簽名確保 Token 未被更改。

JWT 如何在 API 中運作

身份驗證：使用者登入。

建立：伺服器建立一個 JWT，並使用 Secret Key（只有伺服器知道）對其進行簽名。

回應：伺服器將 JWT 發送給用戶端。

儲存：用戶端儲存它（通常在 localStorage 或 HttpOnly Cookie 中）。

請求：對於每個後續請求，用戶端在 Authorization Header 中發送 JWT：
Authorization: Bearer <token>

驗證：伺服器接收 Token。它使用其 Secret Key 重新計算簽名。

如果簽名匹配 -> Token 有效且未被篡改。

伺服器使用 Payload 中的資料（例如 user_id）來處理請求。無需查詢資料庫即可檢查會話！

優點和缺點

優點

無狀態：伺服器不需要在 RAM 或資料庫中保留會話記錄。有利於可擴展性。

緊湊：小到足以在 URL、POST 參數或 HTTP Header 中傳送。

跨網域：與 CORS 和行動應用程式配合良好。

缺點

撤銷很困難：由於伺服器不追蹤會話，您無法輕易地在伺服器端將使用者「登出」或在 Token 過期前禁止它。您通常需要「黑名單」（恢復狀態）或較短的過期時間來緩解此問題。

大小：如果您在聲明中放入太多資料，它可能會變大。

安全最佳實踐

始終使用 HTTPS：否則 Token 可能在傳輸過程中被竊取。

短過期時間：保持 exp 簡短（例如 15 分鐘）並使用 Refresh Tokens。

驗證演算法：確保您的伺服器僅接受您預期的演算法（例如，防止 "none" 演算法攻擊）。

關鍵要點

JWT 是用於 AuthN 和 AuthZ 的自包含無狀態 Token。

它們是已簽名的（防篡改）但已編碼的（任何人均可讀取），因此永遠不要在 Payload 中放入機密資訊。

在信任聲明之前，始終驗證簽名。

下一步：現在我們知道如何保護存取，讓我們看看攻擊者發現漏洞時會做什麼。OWASP API 安全 Top 10。

JSON Web Tokens (JWT)

JWT 的結構#

1. Header (標頭)#

2. Payload (Claims/聲明)#

3. Signature (簽名)#

JWT 如何在 API 中運作#

優點和缺點#

優點#

缺點#

安全最佳實踐#

關鍵要點#