開發者工具 · JWT 解碼器

解碼與驗證：JWT 簽名證明了什麼以及解碼器為何跳過它

2026年7月21日 · 工作原理

jwt 安全密碼學

解碼無需密鑰；驗證需要正確的。這篇文章解釋了簽名涵蓋的內容、HMAC 和非對稱驗證有何不同，以及為什麼僅解碼工具誠實地不證明任何內容。

它解碼得很好，所以它一定是有效的－導致接受偽造令牌的假設

在攻擊者寫入新的有效負載並附加任意文字作為第三段後，令牌可以完美解碼。 Base64url 和 JSON 解析是公共轉換；兩者都不檢查誰組裝了字串。因此，「螢幕上出現的索賠」並不能證明發行人創建或批准了這些索賠。

ToolAcre 在多個地方強化了這條邊界。結果始終帶有 `signatureVerified: false`，UI 在輸出旁邊重複未驗證的宣告警報，並測試斷言不存在 `valid` 或 `verify` 表面。這是刻意的誠實，而不是缺失的便利功能。

對於緊湊型 JWS，簽章輸入是編碼的受保護標頭段、文字點和編碼的有效負載段。驗證涉及那些確切的編碼字節，而不是新列印的漂亮的 JSON。即使人類看到相同的對象，重新排序屬性或更改空白也可能會建立不同的位元組。

第三段攜帶透過該輸入產生的編碼簽章或 MAC 位元組。 ToolAcre 保留原始段並可能報告其位元組長度，但它從不執行加密檢查。測量資料形狀無法確定預期的密鑰創建了它，或者前兩個段落保持不變。

使用 HMAC，共用金鑰支援建立和檢查 MAC。能夠驗證該秘密的一方也可以鑄造另一個令牌，因此秘密分發定義了信任邊界。 ToolAcre 的註釋對其公認的 HS 演演算法標籤明確說明了這一結果。

非對稱簽章將私人簽章功能與公共驗證資料分開。擁有公鑰可以支援檢查而無需授予簽名權限。這種區別並不會使標頭宣告的非對稱標籤值得信賴：驗證者必須已經知道哪種演演算法和頒發者金鑰是可接受的。

共享機密應來自受保護的服務配置，而不是令牌文字。公共驗證金鑰可以來自受信任的發行者關係和受控金鑰集。 `kid` 可以協助在該集合中進行選擇，但它不得將任意不受信任的標頭內容轉換為檔案、資料庫或網路尋找。

ToolAcre 沒有頒發者配置並不請求金鑰，因此不可能在那裡負責任地執行驗證。通用網頁無法推斷您信任哪個組織、您服務的受眾或您的應用程式允許哪些演演算法。這些是應用程式策略輸入，而不是可透過解碼發現的屬性。

解碼不需要金鑰，因為 base64url 是可逆編碼而不是加密。標頭和有效負載旨在與令牌一起傳輸，並可以由任何持有者恢復。這可以實現有用的檢查，但也意味著機密資訊不應隱藏在編碼字元的視覺噪音後面。

JSON 解析僅新增結構。它可以告訴您 `roles` 是一個陣列或 `exp` 是一個數字，但並不是說這兩個值都是真實的。 ToolAcre 將結構化值呈現為文字，將註冊描述呈現為文件，同時將授權留給可以驗證和執行策略的系統。

從一個合成令牌開始，其有效負載為 `{"sub":"demo","role":"reader"}`。更改一個編碼的有效負載字符，以便位元組仍然形成有效的 JSON，也許會產生不同的角色。兩個版本都可以分割、解碼和漂亮列印。解碼路徑沒有理由拒絕更改的版本。

正確配置的驗證程序會根據變更的簽章輸入重新計算或檢查加密結果並拒絕不符。這種比較顯示了精確的邊界：解碼器成功涵蓋了語法，而驗證者成功可以在評估宣告策略之前建立相對於可信任金鑰和允許演演算法的完整性。

ToolAcre 從不驗證簽名。空段收到警告，格式錯誤的簽章編碼收到另一個警告，可測量位元組被報告為存在但未經驗證。這些分支都不會產生真正的令牌判決。該實作沒有隱藏的金鑰獲取或演演算法執行路徑。

即使成功的密碼驗證也不會自動授權操作。消費服務仍然需要發行者、受眾、時間和特定於應用程式的檢查。本文在庫配置之前停止，因為支援和預設值各不相同；請諮詢您的服務使用的確切驗證程序和版本。

在信任之前進行解碼以進行檢查和驗證。當您需要查看標頭欄位、有效負載值、時間轉換和結構警告時，請使用過期或合成令牌的瀏覽器工具。切勿讓可讀輸出直接影響存取決策。

將後續工作轉移給具有獨立提供的金鑰材料、固定演演算法和服務策略的可信任驗證者。只有該路徑才能測試真實性和完整性，並只有後續的宣告檢查才能決定授權。解碼器拒絕模糊這些工作是一項安全功能。