JWT，全稱 JSON Web Token，是一種用於在兩方之間傳遞聲明的簡潔格式。應用程式在登入後常會使用 JWT：伺服器發出一個 token，用戶端在後續請求中附帶該 token，API 在允許存取前會驗證 token。JWT 並非加密貨幣代幣，其內容也非預設為秘密。
金融、交易所和 Web3 服務的帳戶系統可能在幕後使用基於 token 的驗證。探索數位資產平台的讀者可以創建 Tapbit 帳戶，而開發者應將每個驗證 token 視為安全敏感的憑證。
JWT 是什麼？
JWT 標準 RFC 7519 定義了一種簡潔的聲明格式，旨在作為 JSON 物件進行傳輸。聲明是諸如用戶識別碼、token 發行者、預定受眾或到期時間等陳述。JWT 常被用作存取 token、身分識別 token 或服務間的短期訊息。
人們常說「JWT token」，儘管最後的「T」本身就代表 token。這種重複常見且無害。重要的是要理解 JWT 描述的是一種格式，而非完整的登入系統。安全的驗證還需要正確的發行、驗證、儲存、到期和撤銷策略。
JSON Web Token 如何運作？
典型的登入流程始於用戶提交有效憑證。驗證伺服器會創建一個包含選定聲明的 JWT，並使用數位簽名或訊息驗證碼來保護它。然後，用戶端會將 JWT 提供給 API，通常是透過 HTTP Authorization 標頭，使用 Bearer 方案。
API 會驗證簽名並檢查必要的聲明，然後才信任該請求。重要的檢查可能包括發行者、受眾、到期時間以及應用程式預期的演算法。如果驗證成功，API 會使用聲明來做出授權決定。如果驗證失敗，則應拒絕該請求。
JWT 的三個部分
常見的簽名 JWT 有三個 Base64url 編碼的區段，由點分隔：
header.payload.signature
- Header：識別 token 類型和簽名演算法。
- Payload：包含聲明，例如
sub代表主體、iss代表發行者、aud代表受眾和exp代表到期時間。 - Signature：讓接收者能夠偵測未經授權的變更，並在正確的金鑰被使用時驗證簽署者。
Base64url 編碼不是加密。任何取得普通簽名 JWT 的人通常都可以解碼其標頭和內文。因此，敏感資訊不應放在內文中，除非系統使用了適當的加密格式且有明確需求。
給初學者的 JWT 範例
假設有一個 API 在 Alice 登入後發出一個 token。其內文可能識別 Alice 為主體，命名發行者，指定 API 受眾，並在 15 分鐘後到期。當 Alice 請求她的個人資料時，API 會驗證 token 並使用主體聲明來定位正確的帳戶。
如果有人將內文從 Alice 的識別碼更改為管理員的識別碼，簽名將不再匹配。這就是簽名 JWT 的核心優勢：篡改是可偵測的。然而，有效的簽名並不證明每個聲明都是適當的。API 仍必須確認 token 是來自預期的發行者，並且是為該 API 設計的。
JWT vs Session Cookies vs API Keys
| 方法 | 典型用途 | 狀態儲存位置 | 主要考量 |
|---|---|---|---|
| JWT | 聲明和 API 授權 | Token 攜帶聲明；伺服器可能仍需儲存狀態 | 驗證和撤銷設計 |
| Session cookie | 瀏覽器登入會話 | 通常在伺服器端會話儲存區 | Cookie 和 CSRF 保護 |
| API key | 識別應用程式或專案 | 伺服器將金鑰映射到權限 | 金鑰是長期秘密，除非輪換 |
JWT 並非自動優於 session。Session 可以輕鬆實現即時撤銷，而 JWT 可以減少重複的資料庫查找，並在分散式服務中良好運作。許多系統結合了這兩種方法，例如帶有伺服器管理的重新整理 token 記錄的短期 JWT。
JWT 是否加密？
通常不會。常見的三部分 JWT 通常是簽名的 JSON Web Signature 物件。正確實施後，簽名提供完整性和真實性，但它不會隱藏內文。JSON Web Encryption 是一個相關標準，可以提供機密性，但它使用不同的結構並增加了金鑰管理複雜性。
這個區別很重要，因為開發者有時會將 JWT 貼到解碼器中，卻驚訝地看到可讀的資料。解碼並不等於成功驗證簽名。應用程式絕不應僅僅基於解碼的聲明來授予存取權。
常見 JWT 安全風險
IETF 的 JWT 最佳實務 RFC 8725 解決了實際系統中出現的實施失敗問題。最大的問題通常來自不正確的驗證，而非基本格式本身。
- 演算法混淆：接受意外或不安全的演算法。
- 遺漏聲明檢查：忽略發行者、受眾、到期時間或其他應用程式要求。
- Token 竊取：透過日誌、腳本、不安全的儲存或未受保護的傳輸暴露 Bearer token。
- 金鑰薄弱：使用易猜測的秘密或未能輪換受損的簽名金鑰。
- 過長的到期時間：讓被盜的 token 在過長時間內仍可使用。
- 糟糕的撤銷機制：假設簽名 token 永遠不需要提前失效。
JWT 最佳實務
應用程式應明確僅允許其支援的演算法，驗證每個必要的聲明，並為不同類型的 JWT 使用單獨的驗證規則。Token 應為短期有效，僅透過 HTTPS 傳輸，並從 URL 和常規日誌中排除。簽名金鑰需要安全儲存、輪換和明確的所有權。
儲存取決於應用程式。瀏覽器系統可能使用安全、HttpOnly 和 SameSite 的 cookie，而行動或後端用戶端則使用平台適用的受保護儲存。沒有哪種儲存選擇能消除所有威脅，因此開發者必須綜合考慮跨網站指令碼 (XSS)、跨網站請求偽造 (CSRF)、token 重放和裝置洩漏等風險。
結論
JWT 是一種在系統間攜帶可驗證聲明的簡潔方式。其標頭描述了如何保護它，其內文包含聲明，其簽名有助於接收者偵測篡改。JWT 可以簡化 API 驗證，但前提是接收者必須驗證正確的演算法、發行者、受眾、時間聲明和簽名。對初學者而言，關鍵規則很簡單：JWT 是一種憑證格式，而非證明整個驗證設計是安全的。
常見問題
JWT 代表什麼？
JWT 代表 JSON Web Token，一種標準化的簡潔格式，用於以 JSON 形式傳輸聲明。
任何人都可以解碼 JWT 嗎？
任何擁有標準簽名 JWT 的人通常都可以解碼其標頭和內文。解碼並不驗證簽名，也不使聲明可信。
JWT 和存取 token 相同嗎？
不同。存取 token 描述一種用途，而 JWT 描述一種格式。有些存取 token 是 JWT，有些則是亂碼字串。
JWT 應該持續多久？
沒有通用時長。存取 token 通常是短期的，確切的存留時間取決於系統的風險、撤銷和可用性要求。
JWT 可以被撤銷嗎？
可以，但撤銷需要額外的設計，例如拒絕列表、金鑰輪換、token 版本控制或伺服器管理的重新整理 token 系統。
