セキュリティ

JWT インスペクター

JSON Web Token を貼り付けるだけで、header、payload、claims、有効期限、署名状態をすぐ確認できます。署名を検証したい場合や、テスト用の token を新しく作りたい場合は、HMAC secret、RSA / ECDSA / EdDSA の鍵も利用できます。解析、検証、署名はすべてブラウザ内で行われ、token や鍵がサーバーへ送信されることはありません。

  • 解析、署名検証、署名生成はすべてブラウザ内で完結し、token や鍵はアップロードされません
  • header、payload、signature を自動で分割し、読みやすい JSON として表示します
  • HMAC、RSA、PS、ECDSA、EdDSA の主要アルゴリズムに対応し、対応する鍵を渡せば署名を検証できます
  • exp、iat、nbf は実際の日時に変換して表示されるため、期限切れや時刻ずれを素早く見つけられます
工具/JWT インスペクター
任意

HMAC アルゴリズムでは共有 secret を使います。RSA、PS、ES、EdDSA では PEM または JWK の鍵情報を使います。

入力待ち
左側に token を貼り付けると、header と payload がすぐにここへ表示されます。

概要

Token の中身を読む、署名を検証する、テスト用 token を作る。JWT まわりのよくある作業を、すべてブラウザ内で完結できます。

  1. 01

    Token をまるごとデコード

    Token を header、payload、signature に分割し、手作業で Base64URL デコードしなくても読みやすい JSON として表示します。

  2. 02

    複数アルゴリズムの署名検証

    対応する鍵を指定すれば、HS256〜HS512、RS256〜RS512、PS256〜PS512、ES256〜ES512、EdDSA の署名を検証できます。

  3. 03

    時刻 claim を読みやすい日時へ変換

    exp、iat、nbf を実際の日時として表示します。期限切れ、発行時刻の違和感、サービス間の時刻ずれに気づきやすくなります。

  4. 04

    署名済み token の生成

    Header と payload を編集し、アルゴリズムを選び、対応する鍵を貼り付けると、入力に合わせて新しい token が生成されます。

  5. 05

    鍵の種類を自動で判別

    共有 secret、PEM 公開鍵、PEM 秘密鍵、X.509 証明書、JWK オブジェクトを認識し、選択中のアルゴリズムに合う方法で読み込みます。

  6. 06

    ローカル処理のみ

    Token と鍵はブラウザ内に留まります。ツールを開いている間、それらがサーバーや外部 API へ送信されることはありません。

使い方

確認モードは既存 token の調査に、署名モードはテストやデバッグ用の新しい token 作成に使います。どちらも同じパネルで扱えます。

  1. 01

    確認モードで既存 token を貼り付けます。Header と payload はすぐにデコードされます。

  2. 02

    署名を確認したい場合は、対応する共有 secret、PEM 公開鍵、または JWK を検証用の鍵フィールドに貼り付けます。

  3. 03

    編集可能な header と payload JSON から新しい token を作りたい場合は、署名モードに切り替えます。

  4. 04

    アルゴリズムを選び、対応する secret または秘密鍵を指定します。入力が変わるたびに token が再生成されます。

  5. 05

    出力パネルから生成された token をコピーし、API リクエスト、テスト fixture、ローカル連携に使います。

詳細

作業によって注目すべき token の場所は変わります。目的に合うモードとフィールドを選ぶと、調査がずっと進めやすくなります。

  • 鍵がなくても、確認モードで token にどんな claims が入っているか、期限切れかどうかを確認できます。
  • 確認モードで対応する secret または公開鍵を指定すると、token が本当に期待した発行元から来たものか確認できます。
  • 署名モードでは、ローカル API、単体テスト、mock サービス用の token を、毎回ログインフローを通らずに作れます。
  • HMAC アルゴリズムは同じ共有 secret で署名と検証を行うため、デバッグ中は扱いやすい方式です。
  • RSA、PS、ECDSA、EdDSA は秘密鍵で署名し、公開鍵で検証します。作業内容に合う鍵を用意してください。
  • Payload 内の exp、iat、nbf にホバーすると実際の日時を見られます。時刻ずれの問題はここでかなり早く見つかります。

活用シーン

認証、認可、claim によるルーティングを使うアプリなら、このインスペクターで複数ツールを行き来する手間を減らせます。

  1. ログイン・権限まわりの調査

    401 や 403 を追うときに、ログイン token の subject、roles、scopes、有効期限、署名状態をすばやく確認できます。

  2. バックエンド API の連携テスト

    ローカル API、mock サービス、自動テスト用に、毎回ログインせず予測可能な署名済み token を生成できます。

  3. 外部サービスの token レビュー

    パートナーが発行した token をデコードし、アルゴリズム、発行者、受け手、有効期限がバックエンドの期待と合っているか確認できます。

  4. SSO / OIDC のトラブルシュート

    環境ごとの aud、iss、auth_time を比較し、raw response を直接読むことなく設定差分を見つけられます。

  5. セキュリティレビューと回帰確認

    本番 token が想定したアルゴリズムを使っているか、payload に secret や機微な個人情報が誤って入っていないかを確認できます。

  6. Webhook とコールバックの確認

    Webhook が JWT として届く場合、内容を信頼する前に、署名、送信元、鮮度を確認できます。

関連情報

デコードした header や payload が読みにくい場合は、 JSON フォーマッター で JSON を整えてから署名モードへ戻すと扱いやすくなります。Token 全体ではなく、Base64URL の 1 セグメントだけを確認したい場合は、 Base64 エンコーダー・デコーダー でエンコード / デコードを試すのが手早いです。JWT 以外の API リクエスト署名、Webhook 署名、単独の HMAC digest を扱う場合は、 HMAC ジェネレーター を開いてください。ローカルの HS256 テスト token 用に使い捨て secret が必要な場合は、実際の認証情報を使い回さず パスワードジェネレーター で生成できます。2回発行されたJWTのデコード済みpayloadを比較したい場合（claimsの変化、scopeの絞り込み、audienceの調整の確認など）、2つのJSONを JSON 差分 に貼り付けるとJSON Pathで整理されたフィールド差分を確認でき、長い文字列の単語レベル差分も表示されます。

JWT の中身

JWT はドットで区切られた 3 つのパートでできています。それぞれの役割を知っておくと、問題が起きたときに見るべき場所を絞りやすくなります。

  1. Header

    Token の種類と署名アルゴリズムを表します。通常は typ と alg が入り、使われた鍵を示す kid が含まれることもあります。

  2. Payload

    Issuer、subject、audience、有効期限、アプリ独自のデータなどの claims を持ちます。これは Base64URL エンコードされているだけで暗号化ではないため、token を持っている人なら誰でもデコードして読めます。

  3. Signature

    Header、payload、鍵から計算される値です。Token が改ざんされていないこと、期待した発行元のものであることを確認するために使われ、正しい鍵なしでは同じ署名を再生成できません。

よく使われる標準 claims

RFC 7519 では、よく使われる claim 名が登録されています。Token を調べるときは、下の一覧を見ると代表的なフィールドと値の意味を素早く確認できます。

iss
発行者
この token を発行したサービスや認証基盤を表します。受け取る側は通常、信頼済み発行者の一覧と照合します。
e.g. https://auth.example.com
sub
主体
Token が表す主体を示します。多くの場合はユーザー ID です。同じ発行者の範囲では一意であるべきです。
e.g. user_1234567890
aud
受け手
この token を利用できるサービスやクライアントを示します。受け取る側は、自分の識別子が aud に含まれているか確認します。
e.g. https://api.example.com
exp
有効期限
Unix 秒で表される期限です。この時刻を過ぎた token は受け付けるべきではありません。多くのライブラリは期限切れ token を自動で拒否します。
e.g. 1710003600
nbf
有効開始時刻
Unix 秒で表され、この時刻より前は token がまだ有効ではないことを示します。指定時刻以降にだけ使える token に向いています。
e.g. 1709996400
iat
発行時刻
Token が作成された時刻を Unix 秒で記録します。Token の古さや、サービス間の時刻ずれを確認する手がかりになります。
e.g. 1709996400
jti
Token ID
Token の一意な識別子です。リプレイ対策や、サーバー側の監査ログとの突き合わせに使われます。
e.g. a1b2c3d4-...-e5f6
auth_time
認証時刻
ユーザーが実際に認証を完了した時刻を記録します。OpenID Connect や、直近のログインを要求する SSO フローでよく使われます。
e.g. 1709992800

使い方のヒント

JWT は署名された平文として扱うのが基本です。秘密の入れ物だと思わなければ、多くの失敗を避けられます。

  • Token 内の claims を信頼する前に、正しい secret または公開鍵で署名を検証してください。
  • JWT は署名であり、暗号化ではありません。パスワード、鍵、機微な個人情報を payload に入れないでください。
  • 本番の署名鍵や秘密鍵は、鍵管理システムに保管してください。ブラウザツール、チャット、スクリーンショットに貼り付けないでください。
  • アルゴリズムと鍵の種類は必ず合わせてください。HS256 で署名された token は HS512 では検証できず、RSA 公開鍵で HMAC token を検証することもできません。
  • 認証問題を調べるときは、exp、iat、nbf を早めに確認し、発行側と受信側のシステム時刻を比べてください。時刻ずれは見落とされがちです。
  • 長く使える token には refresh の仕組みと失効戦略を組み合わせ、漏れた token が使える時間をできるだけ短くしてください。

制限事項

このツールで扱わない範囲を知っておくと、JWT の安全性や互換性を正しく判断できます。

  • 対応しているのは compact JWS token です。暗号化された JWE token は対象外です。
  • Token と鍵は保存されません。タブを閉じると、入力中の内容は破棄されます。
  • Header または payload の JSON が無効な場合、JSON を直すまで token には署名できません。
  • このツールは鍵管理サービスではありません。長期利用の鍵や master key を、オンラインツールに貼り付けることは避けてください。このページも例外ではありません。
  • 非常に大きな payload ではエディタが重くなることがあります。ただし処理はローカルで行われ、内容が切り詰められたりアップロードされたりすることはありません。

よくある質問

署名と暗号化の違い、検証失敗の原因、対応アルゴリズム、データがローカルに留まる仕組みについて、よくある質問をまとめました。

JWT は暗号化されていますか？

多くの JWT は署名されているだけで、暗号化されていません。Token を持っている人は payload をデコードできます。暗号化が必要な場合は、通常の JWS ではなく JWE を使います。

署名検証が失敗し続けるのはなぜですか？

よくある原因は、鍵が違う、header の alg と別のアルゴリズムを使っている、署名後に payload が変更された、または別の鍵セットで発行された token を検証していることです。まず header の alg と指定した鍵の種類を比べてください。

本番の secret をこのツールで使ってもいいですか？

このツールは token の確認、デバッグ、ローカルテスト用 token の生成に使うのがおすすめです。本番 secret や秘密鍵は安全な鍵管理システムに置き、ブラウザツールや共有画面には出さないでください。

ページは token や鍵をどこかへ送信しますか？

送信しません。解析、署名検証、署名生成はすべてブラウザ内で行われます。このページが token や鍵をサーバーへ送るネットワーク処理はありません。

どのアルゴリズムに対応していますか？

HS256、HS384、HS512、RS256、RS384、RS512、PS256、PS384、PS512、ES256、ES384、ES512、EdDSA に対応しています。多くのモダンなバックエンドフレームワークの標準的な選択肢をカバーしています。

exp や iat が日時として表示されるのはなぜですか？

標準では、これらの claim は Unix epoch 秒で保存されます。ツール側で読みやすい日時に変換することで、期限切れや時刻ずれをすぐ確認できます。

デコードした payload はそのまま信頼できますか？

署名検証に成功した場合にだけ信頼できます。単にデコードできるということは、payload が JSON として読めるというだけで、期待した発行元から来たことや改ざんされていないことは保証しません。

関連ツール

パスワード生成、ハッシュ計算、署名チェックなど、セキュリティと認証まわりの作業を続けられます。