§

JWT を貼り付けてください

解析と署名検証はどちらもローカルで実行されます。トークンに関する情報がサーバーへ送信されることはありません。
§

ヘッダー

json
§

ペイロード

json
§

署名を検証

署名を検証するにはシークレットを入力してください。

国内 SaaS の認証基盤では、AWS Cognito (Tokyo)、Auth0 Japan、Okta、freee や Money Forward の OAuth トークンとして JWT が広く採用されています。LINE ログインの ID トークン、メルペイの決済フローで発行されるアクセストークン、全銀協オープン API(FAPI 準拠)のクライアント認証 JWS など、payload と exp・iss を目視で確認したい場面が頻発します。FISC 安全対策基準の下で外部 jwt.io へ貼り付けられない環境でも、本ツールはブラウザ内で完結します。

JSON Web Token とは何ですか?

JSON Web Token(JWT)は、小さなクレームのペイロードを運ぶための、コンパクトで URL セーフなエンベロープです。ステートレスなウェブセッション、OAuth/OIDC ID トークン、マシン間 API 認証、署名付きマジックリンクなどに使われる、標準的な資格情報フォーマットです。JWT は常に、ドットで連結された 3 つの base64url セグメント、すなわち header.payload.signature で構成されます。ヘッダーとペイロードは JSON で、シグネチャーは最初の 2 セグメントに対するバイナリの MAC または電子署名です。

JWT はどのように機能しますか?

このツールがトークンをデコードする際は、すべての JWT ライブラリと同じ 3 ステップの手順をたどります:

  1. トークンをドットで分割し、空でない 3 つのセグメントになることを確認します。それ以外の形は不正です。
  2. セグメント 0 と 1 を base64url デコードしてから、それぞれを JSON.parse します。ヘッダーにはアルゴリズム(alg)とトークンタイプ(typ)が、ペイロードにはクレーム(subexpiat、カスタムキー)が含まれます。
  3. シークレットが提供されている場合、ヘッダーで指定されたアルゴリズムを使って <segment0>.<segment1> に対する MAC を再計算します。そのバイト列を 3 つ目のセグメントと比較します。
  4. デコードされたクレームとともに検証結果を表示し、exp クレームから計算した人間に読みやすい有効期限の表示も併せて提供します。

ブラウザで JWT をデコードする理由は何ですか?

実運用中の本物の JWT をリモートデバッガーに貼り付けると、その資格情報はそのサービスのログ、可観測性スタック、さらにはサービスがデータを共有している任意のパートナーへ漏れる可能性があります。たとえそのサードパーティのサイトがトークンを記録していないと主張していても、それを検証する手段はありません。このツールは、そうした妥協をする必要がないように作られています:

  • ゼロネットワーク:このランタイムには fetchXMLHttpRequestsendBeacon の呼び出しが一切ありません。デコードや検証を行いながら DevTools を開いてみてください — Network パネルは無音のままです。
  • ネイティブ Web Crypto:HMAC 検証には crypto.subtle.importKeycrypto.subtle.sign を使用しており、これはあなたのランタイムが内部で呼び出すのと同じプリミティブです。
  • 静的デプロイ:すべてのページは 1 つの静的 HTML ファイルであり、侵害される対象のサーバーエンドポイントはありません。漏えいさせるサーバーが存在しないので、漏れるトークンも存在しません。

このツールは何を検証し、何を検証しないのですか?

このツールのバージョン 1 では、HMAC-SHA 系の署名のみを検証します。具体的には:

  • 対応: HS256、HS384、HS512。共有シークレットを提供すれば、ツールが MAC を再計算して比較します。
  • 未対応: RS256/384/512(RSA)、ES256/384/512(ECDSA)、EdDSA、PS256/384/512(RSA-PSS)。これらは PEM または JWK 形式の公開鍵を必要とするため、後続のリリースに意図的に先送りしています。
  • 拒否: alg: "none"。ツールはトークンをデコードしつつ、明示的に安全ではないものとしてフラグを立てます — 署名検証は一切行われておらず、そうしたトークンを受け入れる本番システムは深刻な脆弱性を抱えています。

JWT デコードの例はどのようなものですか?

上の入力フィールドに、定番の RFC 7519 サンプルトークンを貼り付けてみてください:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

ヘッダーは {"alg":"HS256","typ":"JWT"} に、ペイロードは {"sub":"1234567890","name":"John Doe","iat":1516239022} にデコードされます。検証パネルに your-256-bit-secret を入力すると、署名チェックは「有効」を返します。シークレットの文字を 1 つでも変えれば「無効」を返します。これらのいずれの処理もあなたのブラウザーから外に出ることはありません。

これは、本番環境でトークンをデバッグする必要があったときに「あればよかった」と思った JWT デコーダーです:プライバシーを尊重し、高速で、ランタイムが使うのと同じプリミティブの上に構築されています。