JWT デコーダ: トークンの中に何が入っていて、何が入っていないの

3つの部分

• ヘッダー - 署名アルゴリズム (`alg`) とトークン タイプ (`typ`) (HS256 など)。
• ペイロード — クレーム: トークンが誰に関するものなのか、いつ発行され、いつ期限切れになるのか。
• 署名 — 発行者のキーを使用して最初の 2 つのセグメントに基づいて計算されます。これが、デコーダーが署名を表示してもチェックできない理由です。

                eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjMiLCJleHAiOjE3NjAwMDAwMDB9 . signature
           header                            payload                       signature
              

ほとんどの失敗を説明する主張

• `exp` (有効期限) — 401 の最も一般的な原因。2 分前に有効期限が切れたトークンは、他のものが検査される前に拒否されます。
• `nbf` (以前ではない) — 鏡像: 有効期間が拒否される前に使用されたトークン。
• `iat` (発行日)​​ — セッションの古さを調べたり、一致しないクロックを特定したりするのに役立ちます。
• `aud` (視聴者) と `iss` (発行者) - ここでの不一致は、トークンは有効であるが、別のサービスに対して発行されたため、混乱を招く形で失敗することを意味します。

時間要求は、Unix エポックからの UTC 秒数です。トークンが有効であるように見えても、有効期限が早すぎるか遅すぎる場合は、クロックの問題、または秒が予期されていた部分にミリ秒を運ぶペイロードがないかどうかを確認してください。

`alg` を盲目的に信頼してはいけない理由

2 つの攻撃は有名になるのに十分古いものですが、まだ実際に出現しています。 `none` アルゴリズムは、署名がまったく存在しないことを検証者に伝えます。サーバーは、独自の予期されたアルゴリズムを強制するのではなく、ヘッダーを読み取ると、それを受け入れます。そして、RSA/HS の混乱の中で、攻撃者は公開キーを HMAC シークレットとして署名し、両方のファミリーを受け入れるサーバーを騙します。どちらの場合も防御はデコーダではなく検証器にあります。期待されるアルゴリズムをサーバー側に固定し、トークン自体から決して導出しないようにします。

常にローカルでデコードする

JWT は資格情報です。それを保持している人は、有効期限が切れるまでユーザーとして機能できます。本物のファイルを Web サイトに貼り付け、それをサーバーに投稿すると、ライブ セッションが引き渡され、利益はゼロです。デコードは、どのブラウザでもマイクロ秒で実行できる Base64URL 演算であるためです。 YamlBox JWT デコーダは、ページ内のトークンを解析し、タイムスタンプ クレームを読み取り可能な UTC 日付として表示し、ネットワークが無効になっても動作し続けます。これは、実稼働トークンで使用する価値のある唯一の種類のデコーダです。

機能するデバッグルーチン

1. 最初に `exp` をデコードして読み取ります。すべての「無効なトークン」レポートの半分はここで終了します。
2. `aud` と `iss` を API が期待するものと照らし合わせてチェックし、次に `nbf` でクロック スキューを確認します。
3. デコードされたクレームを、コードがロールまたはスコープに関して想定している内容と比較します。
4. 主張が正しいように見えてもまだ失敗する場合、問題は検証です。つまり、間違ったキー、ローテーションされたシークレット、またはアルゴリズムの不一致です。