JWT デコーダー
JSON Web Token（JWT）は2つの当事者間でクレームを表現するコンパクトでURLセーフな方法です。ほとんどのJWTはJWS（JSON Web Signature）を使用して署名されており、完全性は保証しますがコンテンツは暗号化しません。このツールはヘッダーとペイロードをデコードしてクレームを表示し、タイムスタンプを人間が読める形式で表示し、トークンの有効期限状態を表示します。
仕様
よくあるユースケース
- OAuth 2.0およびOpenID Connect認証フローのデバッグ
- IDプロバイダー（Auth0、Okta、Keycloak）からのアクセストークンとIDトークンの検査
- API開発中にトークンクレームが期待値と一致するか検証
- 「401 Unauthorized」エラーのトラブルシューティング時のトークン有効期限の確認
- サードパーティサービスとの統合時のトークン構造の理解
- セキュリティレビューのためのトークン監査（アルゴリズム、クレーム、有効期限）
機能
- JWTヘッダーとペイロードのデコード（JWS形式）
- アルゴリズム（HS256、RS256、ES256、PS256、EdDSA）とトークンタイプの表示
- 登録済みクレームの解析: iss（発行者）、sub（サブジェクト）、aud（オーディエンス）、exp（有効期限）、nbf（有効開始日時）、iat（発行日時）、jti（JWT ID）
- 人間が読めるカウントダウン付き有効期限状態の表示
- デコードされたセクションをフォーマットされたJSONとしてコピー
例
OAuth 2.0アクセストークン
試してみる →サブジェクト、発行者、有効期限を含む標準クレーム付きの典型的なアクセストークン。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5ヒント
- JWSトークン（最も一般的なタイプ）は署名されていますが暗号化されていません。トークンを持つ誰でもBase64デコードすることでペイロードを読むことができます。
- JWEトークンはペイロードを暗号化しますが、あまり一般的ではありません。このツールはJWSトークンをデコードします。
- クレームを信頼する前に、常にサーバーサイドで署名を検証してください。このツールはデコードされたコンテンツを表示しますが、署名は検証しません。
- "alg": "none"アルゴリズムはセキュリティリスクであり、サーバーで拒否すべきです。
- 対称アルゴリズム（HS256）は共有シークレットを使用します。非対称アルゴリズム（RS256、ES256）は公開鍵/秘密鍵ペアを使用します。
- "exp"クレームは秒単位のUnixタイムスタンプです。期限切れのトークンを受け入れないよう確認してください。
解説 JWT デコーダー
JSON Web Token（JWT）はモダンWeb認証・認可の支配的なトークンフォーマットです。JWTはドットで区切られた3つのBase64urlエンコードされたセグメントで構成されるコンパクトでURLセーフな文字列です: 署名アルゴリズムを指定するヘッダー、ユーザーまたはセッションに関するクレームを含むペイロード、トークンが改ざんされていないことを保証する暗号署名です。この構造により、任意の当事者がシンプルなBase64デコードでトークンの内容を読むことができますが、有効なトークンの作成や検証は署名鍵を持つ当事者のみが行えます。
ほとんどのJWTはJWS（JSON Web Signature）形式を使用し、ペイロードは署名されますが暗号化されません。ヘッダーの"alg"フィールドはアルゴリズムを指定します: HS256のような対称アルゴリズムは発行者と検証者の両方に知られている共有シークレットを使用し、RS256やES256のような非対称アルゴリズムは署名に秘密鍵、検証に公開鍵を使用します。分散システムでは、検証鍵を署名鍵を危険にさらすことなく公開できるため、非対称アルゴリズムが好まれます。
ペイロードにはRFC 7519で定義された登録済みクレームが含まれます: "iss"（発行者）、"sub"（サブジェクト）、"aud"（オーディエンス）、"exp"（有効期限）、"nbf"（有効開始日時）、"iat"（発行日時）、"jti"（JWT ID）。OAuth 2.0とOpenID Connectはスコープ、ロール、ユーザープロファイル情報のための追加クレームを重ねます。"exp"クレームはセキュリティに不可欠です。有効期限のないトークンや過度に長い有効期間のトークンは一般的な脆弱性です。
JWTはOAuth 2.0アクセストークン、OpenID Connect IDトークン、API認証、セッション管理で使用されます。Auth0、Okta、KeycloakなどのIDプロバイダーはJWTを発行し、アプリケーションはプロバイダーに問い合わせることなく検証でき、ステートレス認証を可能にします。ただし、これは取り消しが困難であることも意味します。侵害されたトークンは期限切れになるまで有効なままであるため、短い有効期限とトークンリフレッシュフローは不可欠なセキュリティプラクティスです。
JWSトークンは暗号化ではなくBase64urlエンコードされているため、トークンを所有する誰でもヘッダーとペイロードをデコードして読むことができます。パスワード、クレジットカード番号、シークレットなどの機密情報はJWTペイロードに決して入れるべきではありません。JWE（JSON Web Encryption）トークンはペイロードを暗号化しますが、実際にはあまり一般的ではありません。エンコーディングと暗号化の違いはJWTを扱う際に理解すべき最も重要なことの1つです。
署名アルゴリズムの選択はセキュリティに大きな影響を与えます。HS256は署名と検証の両方に単一の共有シークレットを使用する対称アルゴリズムで、実装が簡単ですが両者が同じシークレットを安全に保存する必要があります。RS256とES256は署名に秘密鍵、検証に公開鍵を使用する非対称アルゴリズムです。分散システムでは、公開鍵を（多くの場合JWKS（JSON Web Key Set）エンドポイントを通じて）署名鍵を危険にさらすことなくオープンに共有できるため、非対称アルゴリズムが好まれます。"alg": "none"オプションは署名なしのトークンを示し、誰でも任意のクレームでトークンを偽造できることを意味します。よく知られた攻撃は、アルゴリズムヘッダーを"none"に変更して署名を削除することです。サーバーは常にアルゴリズムを許可リストに対して検証し、署名なしトークンを拒否すべきです。
適切な有効期限の処理はJWTセキュリティに不可欠です。アプリケーションはトークンを信頼する前に、すべてのリクエストで"exp"クレームをチェックすべきです。トークンが期限切れになると、リフレッシュトークン（安全に保存され、多くの場合httpOnly Cookieに）を使用して、ユーザーに再ログインを要求せずに新しいアクセストークンを取得できます。アクセストークンの有効期間を短く保つこと（通常5〜15分）は、トークンが侵害された場合の露出ウィンドウを制限します。アクセストークンが実際に期限切れになる前にプロアクティブにトークンリフレッシュを実装することで、アプリケーションでのユーザー向けの中断を回避できます。