使用方法
- 貼上完整的權杖，即用點號分隔的三段 Base64URL。
- 檢視解碼後的頭部和載荷。exp、iat 和 nbf 會顯示為日期，權杖已過期或尚未生效時會給出提示。
- 如需驗證簽名，HS256、HS384、HS512 請輸入共享金鑰，RS、PS、ES 系列演算法請貼上 PEM 格式的公鑰。
- 確認簽發者、受眾和主題等宣告與你的應用預期一致。
JWT 的結構
JSON Web Token（RFC 7519）由點號分隔的三部分組成：header.payload.signature。頭部和載荷都是 JSON 物件，經過不帶填充的 Base64URL 編碼，所以權杖幾乎總是以 eyJ 開頭，這正是開頭的 {" 編碼後的樣子。簽名則是對前兩部分（按權杖中的原樣）計算得出的。
- 頭部：在
alg中指明簽名演算法，通常帶有"typ": "JWT"，並常用kid標明所用的金鑰。 - 載荷：即各項宣告，例如使用者是誰、權杖由誰簽發、何時過期。
- 簽名：HMAC、RSA 或 ECDSA 簽名，用來證明頭部和載荷未被篡改。
如果權杖由五部分組成，那就是加密的 JWE，沒有解密金鑰無法讀取其內容。
註冊宣告
| 宣告 | 名稱 | 含義 |
|---|---|---|
iss | 簽發者 | 建立並簽名該權杖的一方 |
sub | 主題 | 權杖所代表的物件，通常是使用者 ID |
aud | 受眾 | 權杖的目標服務 |
exp | 過期時間 | 超過該時間後必須拒絕該權杖 |
nbf | 生效時間 | 早於該時間時必須拒絕該權杖 |
iat | 簽發時間 | 權杖的建立時間 |
jti | JWT ID | 唯一標識，用於防止重放 |
時間採用 NumericDate 格式，即自 1970 年 1 月 1 日 UTC 起的秒數，而不是毫秒數。解碼工具會把它們顯示為易讀的日期，並與你裝置上的時鐘進行比較。
解碼不等於驗證
任何人都能解碼 JWT，因為載荷只是經過編碼，並沒有加密，所以絕不要在其中存放密碼或其他機密資訊。權杖是否可信，只能通過用正確的金鑰驗證簽名來確認。接收權杖的伺服器還應當：
- 只允許預期的演算法，並拒絕
"alg": "none"，它表示權杖沒有簽名； - 絕不能讓權杖頭部決定使用 HMAC 還是 RSA，否則攻擊者可以把你的公鑰當作 HMAC 金鑰來偽造權杖；
- 每次請求都檢查
exp、nbf、iss和aud。
本頁的簽名驗證功能使用瀏覽器內建的 Web Crypto API，解碼和驗證都在你的裝置上完成，不會上傳任何內容。但作為通用原則，切勿把生產環境的簽名金鑰或仍然有效的權杖貼上到你不信任的網站上。
常見問題
把 JWT 貼上到這裡安全嗎？
權杖由瀏覽器中的 JavaScript 解碼和驗證，不會發送到任何伺服器。但請記住，未過期的權杖對持有者來說就相當於密碼，分享截圖或日誌時最好使用測試權杖或已過期的權杖。
沒有金鑰也能解碼 JWT 嗎？
可以。頭部和載荷只是經過 Base64URL 編碼的 JSON，不需要任何金鑰就能讀取。只有驗證簽名時才需要金鑰或公鑰。
為什麼提示我的權杖已過期？
exp 宣告早於你裝置上的當前時間。如果權杖本應仍然有效，請檢查系統時鐘以及簽發方設定的權杖有效期。支援驗證哪些簽名演算法？
使用共享金鑰的 HS256、HS384、HS512，以及使用 PEM 格式公鑰的 RS256、RS384、RS512、PS256、PS384、PS512、ES256、ES384 和 ES512。
"alg": "none" 是什麼意思？
它表示權杖未經保護、簽名為空，由 RFC 7518 定義。任何人都可以建立或修改這樣的權杖，因此要求籤名權杖的伺服器必須始終拒絕它。