開發者工具 · JWT 解碼器
受眾和發行者檢查：阻止 JWT 在其他地方重播
· 為什麼它很重要
jwt 身份驗證 安全
為一項服務所發行的令牌可以提供給共享相同發行者的另一項服務。這篇文章解釋了 aud 和 iss 檢查如何阻止這種情況，以及如何讀取令牌中的兩個宣告。
服務 B 接受用於服務 A 的令牌 — 有效簽章不會阻止跨服務重播
簽章對於發給不同服務的代幣可能有效。如果多個 API 信任相同的身分平台但忽略接收者上下文，則用於服務 A 的憑證可能會在服務 B 上重播。密碼完整性本身並不能回答誰應該使用它。
ToolAcre 可以顯示 `iss` 和 `aud`，以便開發人員可以發現明顯的不符。在簽章成功之前，這些字串將保持未驗證狀態，瀏覽器工具永遠不會執行該檢查。實際的資源伺服器必須強制執行其發布者關係和目標受眾。
iss — 將令牌綁定到您的服務信任的頒發者，以及為什麼在沒有密鑰綁定的情況下字串匹配是不夠的
`iss` 標識有效負載宣告頒發令牌的實體。驗證者需要在自己的配置下有一個確切的預期發行者，並必須將該身分綁定到正確的金鑰發現關係。比較沒有加密綁定的文字為攻擊者複製預期字串留下了空間。
解碼器將 `iss` 描述為“誰創建了令牌”，但這是註冊的含義，而不是關於貼上值的發現。可讀的發行者文字是調試配置的有用證據。它無法選擇任意金鑰來源或對自身進行身份驗證。
aud — 命名預期接收者的字串或陣列，以及驗證者必須在其中找到自己的規則
`aud` 命名預期收件人，可能顯示為一個字串或一個集合。資源伺服器的策略必須使用其設定檔所需的精確比較規則在經過身份驗證的值中找到自己。它不應僅僅因為列出了其他一些熟悉的服務而接受令牌。
ToolAcre 在其宣告表中將陣列作為 JSON 文字，保留其可見結構以供檢查。它不知道當前 API 的標識符，無法決定匹配。這種故意的缺席阻止了通用解碼器發明它不擁有的授權上下文。
azp 和範圍 — OpenID Connect 和 OAuth 宣告，細化了誰可以使用令牌以及用途
`azp` 和 `scope` 可以在定義它們的設定檔中加入有關授權方和請求權限的上下文。它們不會取代受眾、發行者或簽名檢查。在資源伺服器將經過身份驗證的值對應到自己的策略之前，範圍名稱是一個斷言，而不是權限授予。
目前解碼器將這些視為特定於應用程式的宣告，因為其註冊描述表涵蓋了七個核心名稱。它顯示它們的值，但不提供 OpenID Connect 或 OAuth 語義。在做出決定之前，請先查閱適用的設定檔和提供者合約。
混淆代理模式 — 當受眾未經檢查時，合法令牌如何成為攻擊
困惑的代表在意想不到的情況下使用合法權力。即使沒有人偽造簽名，錯誤服務接受的令牌也可能準確觸發該模式。受眾檢查限制了可以應用經過身份驗證的宣告的位置，而發行者檢查則限制了服務考慮的斷言。
這就是為什麼一般的「簽名有效」標誌仍然不夠。授權取決於接收者和操作。 ToolAcre 不報告驗證結果來完全避免這種歧義，讓消費服務將加密與上下文策略結合。
工作範例 — 從 ToolAcre JWT 解碼器中的兩個令牌讀取 iss 和 aud 並決定哪個服務應接受每個令牌
建立兩個無害的令牌，其解碼的有效負載僅在 `aud` 上有所不同：一個名稱為 `service-a`，另一個名稱為 `service-b`；兩者都聲稱是同一發行人。 ToolAcre 讓差異顯而易見。服務 A 驗證者不僅不應接受來自此顯示的內容，而且應拒絕經過驗證的服務 B 受眾。
然後用兩個頒發者字串反轉練習。除非使用該發行者信任的金鑰進行驗證，否則僅預期文字是不夠的。這些範例將檢查與接受分開，並說明了為什麼將看似正確的宣告複製到偽造的令牌中不會改變可信任策略。
這不包括簽名驗證，解碼器從不執行； aud 和 iss 檢查僅在簽名生效後才起作用
只有在加密驗證確定受保護的位元組對應於可信任金鑰資料之後，受眾和發行者檢查才有意義。 ToolAcre 不執行任何驗證。其輸出無法確定索賠完好無損或由已知發行人撰寫。
它也不會取得元資料、選擇金鑰或比較配置的收件者。使用後端測試和日誌來證明對錯誤發行者和錯誤受眾的拒絕。解碼器中的視覺匹配是調試線索，而不是足夠的授權證據。
重點：檢查它的用途，而不僅僅是簽名者 — ToolAcre JWT 解碼器顯示您需要比較的 aud 和 iss 宣告
檢查令牌的用途，而不僅僅是其簽名的名稱。強大的流程在獨立可信任的發行者關係下對受保護的位元組進行身份驗證，然後需要可接受的受眾並應用特定於服務的授權規則。
使用 ToolAcre 讀取安全測試值並制定下一個伺服器端檢查。不要從不受信任的標頭或宣告資料中選擇驗證金鑰，也不要在沒有完全可信任流程的情況下將顯示的 `iss`、`aud`、`azp` 或 `scope` 轉換為授權。