ToolActToolAct

JWT 解析ツール

JSON Web Tokenをデコード・検証、Header、Payload、Signatureを確認

JWT Token

サンプル JWT

JWTとは？

JWT (JSON Web Token) は、当事者間で安全に情報を送信するためのオープン標準 (RFC 7519) です。JWTはドットで区切られた3つの部分で構成されます：Header（ヘッダー）はトークンタイプと署名アルゴリズムを含み、Payload（ペイロード）はクレームデータを含み、Signature（署名）はトークンの整合性を検証します。JWTは認証と情報交換シーンで広く使用されています。

使い方

使い方

  1. JWTを入力ボックスに貼り付けると、ヘッダーとペイロードの内容が自動的に解析・表示されます
  2. 色付きタグをクリックすると、対応するBase64エンコード部分をコピーできます
  3. 署名検証エリアにシークレットを入力すると、署名の正当性を検証できます（HS256/HS384/HS512アルゴリズム対応）
  4. 主要情報エリアに一般的なクレームのデコード値が表示され、有効期限の状態は色分けされています

セキュリティのヒント

  • このツールはブラウザ上でローカルに動作し、Tokenがサーバーに送信されることはありません
  • JWTはデータをエンコードおよび署名するだけです。暗号化ではないため、誰でもデコードして内容を閲覧できます
  • JWTに機密情報を保存しないでください（パスワード、クレジットカード番号など）
  • 本番環境では必ずHTTPSを使用してJWTを送信してください

利用シーン

認証デバッグ中にトークンの内容を確認する3パートのJWT（Header.Payload.Signature）を貼り付けて、Base64URLデコードされたヘッダーとペイロードを署名とは別に確認します。iss、aud、sub、iat、nbf、expなどの標準クレームはUnix秒と人間が読みやすい日付で表示されるため、ログインやセッションの問題を把握しやすくなります。トークンはブラウザタブの外に出ません。
HMAC署名をローカルで検証するHS256、HS384、HS512トークンについて、共有シークレットを入力すると、header_b64 + '.' + payload_b64に対してHMAC-SHA256/384/512を再計算し、署名セグメントと比較します。環境の比較、ローテーションされたシークレットの診断、トークンが転送中に改ざんされていないことを確認する際に役立ちます。貼り付けたシークレットはローカルHMACにのみ使用され、サーバーに送信されることはありません。
ログ共有前に有効期限とクレーム詳細を確認するこのツールは期限切れトークン（exp < 現在時刻）をハイライトし、nbf/iatの境界を表示するため、「正しく署名されているがまだ有効でない」トークンも検出されます。生のパーツまたはフォーマットされたJSONをコピーできます。デコードとHMAC検証はブラウザ内で行われるため、機密性の高いベアラートークンを外部デコーダーサービスに送信せずに確認できます。
公開鍵署名トークンの内容を確認する（ローカルでは検証しない）RS256、PS256、または ES256 で署名されたトークンを貼り付けると、デコードされたヘッダーとペイロードを確認できます。本ページがローカルで検証するのは HMAC（HS256/HS384/HS512）署名のみで、RSA / RSA-PSS / ECDSA の署名検証は対応する公開鍵を保持するサーバー側（通常は発行者の JWKS エンドポイントから読み込む）で行う必要があります。OAuth コールバックの調査でローカルタブをトークンの内容確認だけに使う場面で役立ちます。
アルゴリズムの混同とexpクレームの欠落を発見するデコードビューはヘッダーのalgを標準クレームと一緒に表示するため、トークンがHS256なのにサーバーがRS256を期待している（古典的なアルゴリズム置換攻撃）、algが「none」になっている、exp/nbf/iatが欠落している場合が一目瞭然になります。バリデーションを密かにダウングレードする可能性のある認証ライブラリに到達する前に、ブラウザでこれらの不一致を検出してください。

仕組み

JWT（JSON Web Token、RFC 7519）は、Header.Payload.Signatureの3つのパートで構成され、英語のピリオド「.」で結合されます。 Header：トークンタイプと署名アルゴリズムを記述します。例：{"alg":"HS256","typ":"JWT"}。algはSignatureの計算方法を決定し、一般的なものとしてHS256（HMAC-SHA256）、RS256（RSA-SHA256）、ES256（ECDSA-SHA256）、none（署名なし - 本番環境では禁止）があります。 Payload：クレームとも呼ばれ、JSONフィールドのセットです。RFC 7519は7つの標準登録クレームを定義しています：iss（発行者）、sub（サブジェクト、通常はユーザーID）、aud（受信者）、exp（有効期限）、nbf（有効開始時刻）、iat（発行時刻）、jti（一意のID）。開発者はuserId、role、tenantなどのプライベートフィールドを自由に追加できます。 Signature：HeaderとPayloadをBase64URLエンコードし、ドットで結合後、algで指定されたアルゴリズムとキーで署名します。HS256はHMAC-SHA256(secret, header_b64 + '.' + payload_b64)を使用し、RS256はRSA秘密鍵を使用します。受信側は同じ方法で署名を再計算し、一致するか確認します。 Base64URLと標準Base64の違い：「+」は「-」に、「/」は「_」に置き換えられ、末尾の「=」パディングは削除されるため、結果をURLパスやクエリ文字列に直接配置でき、パーセントエンコーディングが発生しません。Base64URLは単なる符号化であり、暗号化やセキュリティは提供しないため、誰でもペイロードをデコードして閲覧できることに注意してください。 セキュリティの境界：JWTは「改ざんされていないこと」のみを保証し、「内容が機密であること」は保証しません。よくある間違いとして、ユーザーの電話番号、ID番号、パスワードハッシュをペイロードに格納することがありますが、これは誰もが閲覧可能です。

  • 3パート構造：Header.Payload.Signature、それぞれBase64URLエンコード。署名はHMAC(secret, header_b64 + '.' + payload_b64)またはRSA(privateKey, 同じ入力)です。
  • Base64URLは「+」→「-」、「/」→「_」に置き換え、末尾の「=」パディングを削除するため、エンコード結果をURLに直接配置できます（パーセントエンコーディングが発生しません）。
  • 本ツールはローカルでは HMAC 系列の署名（HS256/HS384/HS512）のみを検証します。RS256 や ES256 などの非対称アルゴリズムは発行者の JWKS エンドポイントが提供する公開鍵を必要とするため、署名検証は公開鍵を保持するサーバーで行う必要があります——ページではヘッダーとペイロードのデコードはできますが、検証はできません。
  • 標準クレーム：iss（発行者）、sub（サブジェクト）、aud（受信者）、exp（Unixタイムスタンプ秒単位の有効期限）、nbf（有効開始時刻）、iat（発行時刻）、jti（JWT ID、リプレイ防止）。
  • alg=none攻撃：algフィールドを厳密に検証し、noneアルゴリズムを拒否する必要があります。さもなければ攻撃者は任意のトークンを偽造できます。アルゴリズム置換攻撃（公開鍵をシークレットとしてHS256トークンを検証すること）も防止する必要があります。
  • JWTは暗号化されていません：ペイロードはプレーンテキストのBase64URLエンコードであり、暗号化ではありません。機密性の高いコンテンツにはJWE（JSON Web Encryption）を使用しますが、実際には機密データをバックエンドに保持し、subフィールドで参照するのが一般的なパターンです。

使用例

標準的な HS256 トークン

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzA1MzEyODAwLCJleHAiOjE3MDUzMTY0MDB9.znHapMygT8K8YZN4K8zM1sV3bKlQ5pY3xE2gR4wN1vM

Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","name":"Jane Doe","iat":1705312800,"exp":1705316400}
RFC: RFC 7519 section 3 で予約済みクレーム名（sub, iat, exp）が定義されています

期限切れトークン

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsImV4cCI6MTYwMDAwMDAwMH0.OxQ0fUKW0z4mK0xJ4vF0uF7eZB9wK3yF8pL2nQ6tX1k

Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","exp":1600000000}
Status:  期限切れ（exp < 現在時刻）
備考: exp クレームは NumericDate（RFC 7519 section 2 に従い Unix エポックからの秒数）を使用します

カスタムクレーム付きユーザー情報トークン

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQ1NiIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsInRlbmFudCI6ImFjbWUiLCJpYXQiOjE3MDUzMTI4MDAsImV4cCI6MTcwNTMxNjQwMCwiYXVkIjoiYXBpLmV4YW1wbGUuY29tIn0.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4U

Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-456","name":"Alice","role":"admin","tenant":"acme","iat":1705312800,"exp":1705316400,"aud":"api.example.com"}
備考: role と tenant はプライベートクレームで、RFC 7519 では定義されていません

JWT 実装のセキュリティチェックリスト

1. 機密情報を payload に格納しない - JWT はエンコードであって暗号化ではありません
2. HS256 では強力な秘密鍵を使用する（256 ビット以上、ランダムな 32 文字以上）
3. マルチサービス構成では RS256/ES256 など公開鍵検証方式を優先する
4. alg ヘッダーを検証し、'none' や想定外のアルゴリズムは拒否する
5. トークンを信頼する前に exp、nbf、iat のタイムスタンプを確認する
6. aud が自サービスと一致するか検証し、アプリ間でのトークン使い回しを防ぐ
7. localStorage ではなく HttpOnly Cookie に保存する（XSS 対策）

RFC: RFC 8725（JWT Best Practices）にこれらのセキュリティ事項が記載されています

よくある質問

JWT の 3 つの部分とは何ですか？

ヘッダー、ペイロード、署名で、ドットで区切られています。ヘッダーは署名アルゴリズムとトークンタイプを宣言します。ペイロードは sub、iss、aud、iat、exp などのクレームと任意のカスタムデータを運びます。署名により検証側はトークンが改竄されていないことを確認できます。ヘッダーとペイロードは Base64URL エンコードされた JSON で、署名されているだけで暗号化されていません。

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

いいえ。通常の JWS 形式の JWT は署名されていますが暗号化されていません。傍受した者は誰でもヘッダーとペイロードを Base64URL デコードして、ユーザー ID、メール、ロールなどすべてのクレームを読み取れます。JWT の内容は公開情報として扱い、ペイロードにパスワードや秘密情報を決して入れないでください。JWE (暗号化された JWT) も存在しますが、はるかに一般的ではありません。

各標準クレームの意味は何ですか？

iss = 発行者、sub = サブジェクト (多くの場合ユーザー ID)、aud = 対象者 (想定される受信者)、exp = 有効期限 (Unix 秒)、nbf = この時刻以降有効、iat = 発行時刻、jti = 失効用の一意なトークン ID。これらは RFC 7519 で定義されています。カスタムクレームは自由に追加できますが、衝突を避けるためベンダー固有のものはプレフィックスを付けてください。

JWT をどのように検証しますか？

alg ヘッダーを読み、対応する鍵 (HS256 = 共有秘密、RS256/ES256 = 発行者の JWKS エンドポイントの公開鍵) を使用し、エンコードされた header.payload に対して署名を再計算して比較します。次に exp、nbf、iss、aud をチェックします。alg が 'none' であったり、サーバーが期待するものと異なる場合はトークンを拒否してください。 本ツールはローカルでは HS256/HS384/HS512（共有シークレット）の署名のみを検証します。RS256/ES256 の検証は公開鍵を持つサーバー側で行う必要があります。

検証はブラウザ内で行われますか？

はい。ページは JWT をローカルで解析し、HS256/HS384/HS512 の署名はブラウザ内で実行される JavaScript の HMAC で検証します。トークンが当社のサーバーに送られることはありませんが、JWT はもともと URL や HTTP ヘッダーで運ばれる設計なので、コピーした JWT はログに残り得ると考えてください。

なぜ alg=none は危険ですか？

RFC 7519 は未署名トークンに対して alg=none を許可しています。脆弱な検証側は署名がなくてもそうしたトークンを受け入れる可能性があり、攻撃者が任意のペイロードを偽造できてしまいます。最近のライブラリはデフォルトで alg=none を拒否します。自分で検証側を書く場合は、ヘッダーを信頼せず、期待されるアルゴリズムをハードコードしてください。

JWT はどのくらい大きくできますか？

プロトコル上の制限はありませんが、JWT は通常 HTTP ヘッダー (Authorization: Bearer ...) に入り、多くのサーバーはヘッダーを 8 KB 程度で制限します。クレームを詰め込むとリクエストごとに肥大化します。多くのセッション状態が必要な場合は、サーバー側セッションを使用し、JWT には小さな参照トークンだけを入れてください。

関連ツール

JWT 生成器

オンラインJWT生成ツール。HeaderとPayloadをカスタマイズしてTokenを作成。複数アルゴリズム対応、テスト用JWTを素早く生成。

Base64 エンコードデコードツール

オンラインBase64エンコード・デコードツール。UTF-8テキスト、日本語、画像変換をサポート。リアルタイムエンコード・デコード、ソフトウェアインストール不要、データはローカル処理でプライバシー保護。

ハッシュ生成器

オンラインハッシュ生成ツール。MD5、SHA-1、SHA-256、SHA-512など複数アルゴリズム対応。テキストのハッシュ値を素早く生成し、データ検証やパスワード保存に使用。

パスワード生成器

オンライン強力パスワード生成ツール。長さ、文字種類をカスタマイズ。高安全性のランダムパスワードを生成し、ブルートフォース攻撃を防止し、アカウントを保護。

AES 暗号化復号ツール

オンラインAES暗号化・復号化ツール。AES-128/192/256、CBC/GCM/ECBモード、PKCS7パディング対応。ブラウザ内ローカル処理でデータプライバシーを保護。

JSON フォーマットツール

オンラインJSONフォーマットツール。シンタックスハイライト、エラー検出、圧縮・美化をサポート。ワンクリックでJSONデータを美化し、フォーマットエラーを素早く特定し、開発効率を向上させます。