開発者ツール · JWT デコーダー
401 のデバッグ: API を非難する前に、デコードされた JWT で何を確認するか
· なぜそれが重要なのか
jwt デバッグ 認証
トークンの拒否のほとんどは、ペイロードを読み取ることで特定できるいくつかのクレームの問題に起因します。この投稿では、有効期限から視聴者へのコピー＆ペーストのエラーまで、チェックする順番にチェックリストを示します。
昨日は機能しました — コードを変更せずに表示される 401
クライアント コードを変更せずに表示される 401 は、トークンの経過時間、発行者のポリシー、キーのローテーション、対象ユーザーの選択、または破損したコピーに起因する可能性があります。 API がダウンしていると仮定するのではなく、証拠から始めます。資格情報を操作する前に、応答の詳細と相関識別子を保存してください。
期限切れの合成コピーまたは適切に管理されたコピーのみをデコードします。 ToolAcre は構造的な手がかりや要求の手がかりを公開できますが、キー、発行者のポリシー、または API ログがないため、すべてのサーバー拒否を特定することはできません。チェックリストは質問を絞り込みます。リソースサーバーの判定を置き換えるものではありません。
エラーを最初にコピーします — 'Bearer' プレフィックス、末尾の改行、および切り捨てられたトークン
まずコピーした値を確認してください。 ToolAcre は周囲の空白をトリミングし、一般的な Authorization ヘッダーの貼り付けを処理する、大文字と小文字を区別しない `Bearer ` プレフィックスを 1 つ削除します。この場合、ドットで区切られた 3 つのセグメントが必要になります。間違ったカウントは、クレーム分析が開始される前の切り捨て、間違ったトークン形式、または余分な句読点を示しています。
空のヘッダーまたはペイロードは特に失敗します。無効なbase64url、無効な UTF-8、無効な JSON には個別のエラーが発生します。これらの区別は、輸送によってトークンが損傷したかどうかを判断するのに役立ちます。署名は検査をブロックすることなく不正な形式である可能性がありますが、その警告はサーバー側の確認を必要とする検証失敗の可能性が高いままです。
exp および nbf: 表示を有効性の判定に変えずに秒ベースの値を検査します。
次に、数値 `exp` および `nbf` 値を検査します。 ToolAcre は、秒を 1,000 で乗算し、UTC を表示し、ブラウザーの時計を基準にして、以前の有効期限または将来の有効期限をラベル付けします。 13 桁の値により、秒が予想される場所にミリ秒が書き込まれていたことが判明する場合があります。
これらのラベルを施行対象にしないでください。偽造されたトークンは将来の有効期限を要求する可能性があり、サーバーは別のクロックまたは余裕ポリシーを使用する可能性があります。表示により、信頼できるログと比較する価値のある演算が識別されます。クレームが受け入れに影響を与える前に、暗号検証が成功する必要があります。
aud および iss — これは、この API が信頼する発行者からの、この API 用のトークンですか?
`aud` は API のポリシーに基づいて対象の受信者を識別する必要があり、`iss` は信頼できる発行者の関係と一致する必要があります。 ToolAcre は両方をデコードされた値としてリストし、それらの登録された意味を説明します。これらを API 設定と比較したり、発行者文字列をキー セットにバインドしたりすることはありません。
もっともらしい発行者の URL と視聴者名は捏造される可能性があります。署名と検証の境界を維持した後でのみ、正確なデコードされた値をサーバーの構成された期待値と比較します。複数のサービスが ID インフラストラクチャを共有する場合、あるサービスの有効なトークンが別のサービスで使用されることを防ぐために、対象者チェックが特に重要です。
トークンのタイプはヘッダーとクレームによって示唆される可能性がありますが、デコードではその分類を認証できません
ID トークンとアクセス トークンはどちらも 3 部構成の JWT のように見えます。ヘッダー `typ`、対象者、範囲、プロファイル固有の主張から、どれを保持しているかが示唆される場合があります。 ToolAcre は予期しない文字列 `typ` について警告しますが、OpenID Connect または OAuth トークン分類は実装されていません。
発行者のドキュメントとクライアント フローを使用して、予想されるトークンの種類を確立します。 ID トークンの API への送信は、その署名が ID プロバイダーに対して有効な場合でも失敗することがあります。デコードは診断をサポートします。タイプラベルを認証したり、API 権限を付与したりすることはできません。
キーローテーション後の子供 — サーバーが所有しなくなったキーを参照する有効なトークン
キーのローテーション後、ヘッダー `kid` は、サーバーの現在の信頼できるセットに存在しないキーを参照する可能性があります。識別子を読み取り、ベリファイアーのキャッシュとキーセットのログを検査します。ヘッダーが提供する URL をフェッチしたり、簡単な回避策として埋め込まれたキー マテリアルを受け入れたりしないでください。
検証者が許可されたキーを見つけられない場合、正しく署名されたトークンでも失敗する可能性がありますが、攻撃者は未検証のヘッダーに任意の `kid` を書き込むことができます。この値は、信頼できる発行者の構成によって制約される検索ヒントであり、特定のキーが信じられるべきであるという証拠ではありません。
動作する例 — ToolAcre JWT デコーダーのチェックリストを通じて拒否されたトークンを実行する
機能したトリアージの場合は、制御された拒否トークンを取得し、3 つのセグメントを確認し、エラーを検査してから、`exp`、`nbf`、`aud`、`iss`、`typ`、および `kid` を編集せずに記録します。各フィールドをリクエストのターゲット API および検証者の信頼できる構成と比較します。実際の障害カテゴリについてサーバー ログを開いたままにしておきます。
表示されるすべての値が期待通りである場合でも、API が間違っていると結論付ける必要はありません。署名の破損、間違ったキーマテリアル、取り消された状態、または表示されていないポリシーが 401 の原因となる可能性があります。 ToolAcre の `signatureVerified` は、JSON がどれほど整然と表示されているかに関係なく、 false のままです。
これでカバーされていない内容と要点 — デコーダーは署名が有効かどうかを判断できません。チェックリストはクレームの問題を検出し、署名の失敗にはサーバー ログが必要です
デコーダーは、署名が有効かどうかを判断できません。そのクレームチェックリストは、キーなしで見えるコピーとペイロードの問題を見つけます。署名の失敗と権威あるポリシーの決定にはサーバーの証拠が必要です。デコードは、複数の診断結果のうちの 1 つとして扱います。
最速の信頼できるパスが順序付けされます。応答コンテキストを保存し、トークンの形状を検査し、時間単位を比較してから、発行者、対象者、タイプ、およびキー識別子を信頼できる構成と比較します。実際の検証者が暗号化とポリシーを確認するまで、信頼の手前で停止します。