開發者工具 · JWT 解碼器
JWE 解釋：為什麼加密的 JWT 有五個部分且沒有可讀的有效負載
· 背景
jwt 加密 資料格式
有些代幣有四個點而不是兩個，且有效負載不是 JSON。這篇文章解釋了 JWE 緊湊序列化、它的五個部分各自包含什麼內容，以及為什麼沒有一個僅解碼工具可以顯示其宣告。
四個點和一個不是 JSON 的有效負載 — 表示您持有的是 JWE，而不是 JWS
四個点和五個部分表示與熟悉的三部分籤名形式不同的紧凑信封。試著將其中間位元組解析為 JWT 宣告會產生無意義的結果，因為內容是密文，而不是明文 JSON 的 base64url 拼字。
ToolAcre 在解碼前檢查段計數。有五個部分觸發 INVALID_JWT 訊息，該訊息標識 JWE，並解釋了為什麼此僅解碼路由在沒有解密金鑰的情況下無法顯示任何內容。這是一個精確的邊界，而不是模糊的解析失敗。
五個部分－受保護的標頭、加密金鑰、初始化向量、密文和驗證標籤
緊密的 JWE 部分錶示受保護的標頭、加密金鑰材料、初始化值、密文和驗證標記。每個都有獨特的加密角色。單獨的段位置並不能使第二個或第四個欄位成為可讀的 JWT 有效負載。
解碼器可以分割和 base64url 解碼一些字節，但原始字節不能解密。將它們顯示為文字會建立替換字元或誤導性片段。正確的操作是識別信封並轉移到授權的收件者實施。
alg 和 enc — 金鑰管理與內容加密，以及為什麼 JWE 標頭命名兩種演演算法
JWE 標頭可以包含用於金鑰管理的 `alg` 和用於內容加密的 `enc`。這些標籤描述了不同的操作。與簽章令牌一樣，標頭值是必須與接收者策略相符的輸入，而不是令牌選擇任意演演算法的權限。
ToolAcre的三部分演演算法筆記沒有實現JWE處理，五部分分支在頭解析前退出。因此，該頁面不顯示或認可特定的加密演演算法。請諮詢接收者圖書館和發行者合約以獲取支援的選擇。
內容加密金鑰 — 隨機金鑰如何保護有效負載以及自身如何為接收者進行包裝
內容加密通常使用產生的內容加密金鑰，而加密金鑰段在接收方安排下傳送或匯出該金鑰。這種分離允許使用內容密碼來保護有效負載字節，同時金鑰管理策略決定誰可以恢復金鑰。
這個概念模型解釋了為什麼擁有緊湊字串不足以恢復明文。所需的收件人機密和策略未編碼為可免費使用的指示。公用解碼器無法發明它們，也不應該要求使用者將私有解密金鑰貼到通用頁面中。
當發行人選擇 JWE 時 — 必須對客戶或中介機構保密的宣告
當宣告必須對可以看到簽署代幣的持有者或中介機構保密時，發行人可以選擇加密。這是否是正確的選擇取決於威脅模型、密鑰分佈和操作要求。最小化索賠內容仍然比加密不必要的資料更可取。
加密並不能消除授權、驗證或元資料問題。接收者必須驗證受保護的內容並在解密後套用代幣策略。授權接收者所獲得的可讀結果並不會自動為每項服務所接受。
為什麼解碼在標頭處停止 - 有效負載是密文，因此只有密鑰的持有者才能讀取它
解碼在結構處停止，因為可能的有效負載段是密文。 ToolAcre 故意避免將任意二進位檔案顯示為 JSON ，而是提供特定訊息。這可以防止使用者將亂碼解釋為有效加密信封中的損壞。
如果您是預期接收者，請使用配置適當金鑰和演演算法的受控軟體。如果不是，則不可讀的有效負載是預期的安全性屬性。任何填滿技巧或備用字元解碼器都無法取代解密。
這不包括什麼 - 已簽署然後加密的巢狀 JWT，以及 JWE JSON 序列化
巢狀結構可以對內容進行簽名，然後對結果進行加密，或以其他方式在定義的設定檔下方組合層。 JWE 還具有超出緊湊的五部分字串的表示形式。 ToolAcre 不處理這些情況，本文不會僅從標頭標籤推斷嵌套。
在故障排除之前記錄您的系統需要哪個層。否則，團隊可能會嘗試對密文進行簽名驗證或解碼未經身份驗證的內部令牌。讓選定的 JOSE 庫在明確策略下處理排序。
重點：解碼器只能顯示未加密的內容 — ToolAcre JWT 解碼器顯示簽名令牌的標頭和有效負載； JWE 的有效負載在設計上是不可讀的
解碼器只能顯示未加密的內容。 ToolAcre 從三部分簽章輸入的標頭和有效負載中讀取 JSON，而五個段落會導致解釋性停止。這種區別可以防止僅解碼介面假裝具有接收能力。
使用段計數作為路由線索，而不是信任結果。三個可讀部分仍需要簽名驗證；五個加密部分需要授權解密和驗證。在這兩種情況下，視覺輸出本身都不能驗證宣告或授予存取權限。