開發者工具·JWT解碼器
JWT 剖析：點分割與 Base64url 解碼
· 工作原理
傑威特 編碼 安全
JWT 是三個由點分隔的 base64url 區段。這篇文章手動解碼每個部分，解釋為什麼簽名段不是文本，並顯示解碼器可以和不能告訴您什麼。
授權標頭中的長字串 - 您正在查看的內容以及為什麼它恰好有兩個點
持有者令牌通常以緊湊的點分隔字串形式到達授權標頭。緊湊 JWS 形式的典型簽名 JWT 具有三個段，因此有兩個分隔點。活動令牌是一種憑證：請勿將生產令牌貼到演示中。
緊湊序列化 — 標頭、有效負載和簽章作為三個 base64url 段
在緊湊型 JWS 序列化中，第一段是受保護的標頭，第二段是有效負載，第三段是簽章或 MAC。簽名覆蓋編碼的前兩個片段，透過點連接。分割字串定位段；它無法建立信任。
不含填充的 Base64url — JWS 使用的字母表以及為什麼這些段落沒有尾隨等號
Base64url 使用 - 和 _ 來取代普通 Base64 中的 + 和 /。緊湊型 JWS 省略尾隨 = 填充；解碼器可以在解碼之前恢復填充。解碼產生位元組。對於 JSON 標頭和聲明，在解析文字之前將位元組解碼為 UTF-8。
標頭 — 一個小的 JSON 對象，命名演算法，並且通常是金鑰
標頭通常是包含 alg 的 JSON，有時還包含關鍵標識符kid。這些是令牌本身所做的斷言。驗證者必須執行自己的允許演算法策略並安全地取得適當的金鑰；單獨讀取 alg 並不是授權。
有效負載 - 聲明的 JSON 對象，任何持有令牌的人都可以讀取
有效負載包含 sub、exp 和 aud 等聲明。任何持有該令牌的人都可以讀取它們；編碼不是加密。 exp NumericDate 計算自 Unix 紀元以來的秒數，但未經驗證的聲明沒有權威。不要將機密儲存在可讀的有效負載中。
簽章－前兩段的原始字節，作為文字毫無意義，沒有金鑰就毫無用處
最後一段是以 base64url 編碼的簽名字節，而不是第三個 JSON 物件。驗證它需要加密演算法、金鑰和應用程式策略。 ToolAcre 故意不執行驗證：它會報告簽名存在並始終將簽名驗證標記為 false。
工作範例 - 逐段解碼範例令牌，包括出現的 JSON
採用非敏感演示標頭 {"alg":"HS256","typ":"JWT"} 和負載 {"sub":"demo"}。它們的base64url編碼是eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9和eyJzdWIiOiJkZW1vIn0。解碼恢復 JSON。附加任意第三段並不會使令牌變得真實。
重點：解碼是讀取，而不是信任 - ToolAcre JWT 解碼器顯示標頭和有效負載，但從不驗證簽名，因此它顯示的任何內容都不能證明令牌是真實的
解碼是閱讀，而不是信任。使用 ToolAcre JWT 解碼器來取得一次性令牌的標頭、聲明和警告；使用應用程式的可信任驗證程序來確定簽名令牌是否有效。僅顯示的聲明絕不能授予存取權限。