解決方案
使用者登入時,伺服器通常會產生一個會話 ID,並將使用者存入資料表;之後每個請求都會查詢該資料表。這在單一機器上可行,但一群無狀態的 API 伺服器若沒有快取或黏性會話,就無法共用記憶體內的資料表。
JWT 將使用者的聲明移入權杖本身。權杖是精簡、URL 安全的 JSON 載荷,經過簽章,因此無法偽造。伺服器檢查簽章,並直接從權杖讀取聲明。
結果就是無狀態驗證:任何知道公開金鑰的伺服器都能驗證任何使用者,無需共用的會話儲存。聲明與證明一同傳遞,這正是 JWT 成為 API 驗證與單一登入預設方案的原因。
達成了什麼
將聲明放入權杖;簽章就是證明。
為何有效
由於權杖是自包含的,驗證者無需呼叫資料庫,因此請求路徑保持平坦且快速。
信任錨點是簽章而非會話,因此任何持有金鑰的無狀態伺服器都能驗證任何權杖。
其三段式 header.payload.signature 結構,對 Web 生態系中的每種語言而言都易於實作。
它能與 OAuth 及 OpenID Connect 組合,因此同一權杖可跨多項服務與產品使用。
可套用之處
若證明隨聲明一同傳遞,你就能在任何地方驗證,並水平擴展驗證者,因為身分變成自包含,而非一次查詢。
後續發展
JWT 於 2015 年 5 月標準化為 RFC 7519,並包含 JWS/JWE 系列。它成為單頁應用驗證、API 閘道與微服務的預設方案。其已知弱點包括撤銷(權杖在到期前若無拒絕清單就無法失效)與演算法混淆錯誤,以及相較於不透明會話的體積開銷。
追溯依據
參考來源
- RFC 7519: JSON Web Token (JWT) IETF / RFC Editor · rfc-editor.org
- JSON Web Token Wikipedia · en.wikipedia.org