デコードは検証と同じではありません

JWT ペイロードは誰でもデコードできます。トークンは、意図したアルゴリズムとキーで署名検証が成功し、さらに発行者・オーディエンス・時刻・アプリケーションレベルのクレーム検証が完了した後にのみ信頼してください。

トークンを検査・検証する手順

コンパクト JWT を貼り付けると、保護ヘッダーとペイロードを表示し、指定した鍵素材で署名を検証します。HS256/384/512 は生の共有シークレット、RS・PS・ES・EdDSA は公開 JWK または JWKS ドキュメントを使います。想定の発行者とオーディエンスも同じ実行で確認できます。

デコードは検証ではありません。このページはローカルでデコードし、その旨を明示します。署名と登録クレーム（exp、nbf、iss、aud）が通ったときだけ検証済みとして報告します。入力は送信されず、JWKS URL の取得も行わず、鍵素材は保存されません。

トークン欄にコンパクト JWT を貼り付けます。最初のクリックで jose モジュールを読み込むため、最初の結果表示には少し時間がかかります。
鍵素材を貼り付けます。HS256/384/512 は生の共有シークレット、非対称アルゴリズムは公開 JWK または JWKS ドキュメントです。シークレット欄は使用前に前後の空白が除去され、バイト列は UTF-8 として扱われます。
「トークンを検査」でヘッダーとペイロードを信頼せずに読み、「署名を検証」で署名と登録クレームを確認します。
トークンを紐付けたい場合は「想定される発行者」と「想定されるオーディエンス」を入力します。空欄ならその確認は省略されます。
「ローカルの ES256 サンプルを読み込む」はページ内で一時的な鍵ペアを作り、トークンに署名して検証まで行います。自分の鍵がなくても成功例を確認できます。「クリア」で入力欄を空にします。

検証ツールが確認する内容

デコードとその意味

「トークンを検査」はペイロードを JWT デコーダーに通し、保護ヘッダーとペイロードを JSON で表示します。状態表示が警告のままなのは意図的です。トークンを持っている人は誰でも読めるため、デコードされたクレームは「そのトークンがそう名乗っている内容」の下見にすぎません。

署名アルゴリズムを宣言していないトークン（alg が none または欠落）も、ここではそのままデコードします。検査に署名は不要です。それを拒否するのは署名検証です。

「署名を検証」が行う確認

共有シークレットの場合、トークン文字列そのものに対して署名を再計算して比較します。公開鍵の場合は対応する JWK を取り込んで使います。JWKS ドキュメントでは、トークンのヘッダーの kid と一致する鍵を探し、kid がない場合は先頭の鍵を使います。

登録クレームも同じ実行で確認します。exp と nbf は現在時刻と、iss は想定の発行者と、aud は想定のオーディエンスと（入力されている場合に）突き合わせます。状態表示は一般的なエラーではなく、最初に失敗した項目を示します（署名検証の失敗、exp / nbf の時刻確認、想定外または欠落した iss / aud 値）。

クレーム概要と生の出力

概要にはアルゴリズム、キー ID、発行者、オーディエンス、サブジェクト、有効期限が並びます。aud が配列の場合はカンマ区切りの一覧として表示されます。下のパネルはデコード済みトークンを整形した JSON で、protectedHeader と payload が 1 つの文書に入っています。

どちらのパネルも読み取り専用のテキストで、選択してコピーできます。検証に成功してもレイアウトは検査時と同じままで、クレームを信頼できるものにしているのが署名であることを隠しません。

鍵がどこに留まるか

処理はすべてタブ内で、jose ライブラリと Web Crypto API によって行われます。検査・検証の間にページはリクエストを出さず、JWKS URL を取得することもありません（ドキュメントは貼り付けます）。鍵素材はフォーム欄に留まります。

秘密鍵が存在するのはサンプルボタンだけで、それもページ外へ出ません。鍵ペアはブラウザ内で生成し、トークンもそこで署名し、欄に入るのは公開 JWK だけです。つまり鍵のローテーションはここでは手動で、更新した JWKS は貼り直す必要があります。

JWT 署名検証ツール