JWTデコーダー＆インスペクター — 無料オンラインツール

あらゆるJSON Web Tokenを即座にデコード。すべての処理は100%クライアントサイド — トークンはブラウザの外に出ません。

プライバシー保証： このツールはブラウザ内で完全に動作します。ネットワークリクエストは行われません。トークンデータはデバイス上にとどまります。

JSON Web Token（JWT）とは？

JSON Web Token（JWT）は、当事者間で情報をJSONオブジェクトとして安全に送信するためのオープンスタンダード（RFC 7519）です。JWTはWeb APIでの認証や情報交換に広く使用されています。トークンはデジタル署名されているため、整合性を検証できます — ただし、デフォルトではペイロードはBase64エンコードされているだけで、暗号化はされていません。

JWTはドットで区切られた3つの部分で構成されます：ヘッダー（アルゴリズムとトークンタイプ）、ペイロード（クレーム/データ）、署名（トークンが改ざんされていないことを検証するために使用）。

JWT標準クレーム

  • iss（Issuer） — トークンを作成し署名した発行者
  • sub（Subject） — トークンの対象者（通常はユーザーID）
  • aud（Audience） — トークンの対象オーディエンス
  • exp（Expiration Time） — トークンの有効期限（Unixタイムスタンプ）
  • iat（Issued At） — トークンが発行された時刻
  • nbf（Not Before） — この時刻より前はトークンが有効ではない
  • jti（JWT ID） — トークンの一意な識別子

JWTセキュリティのヒント

  • JWTペイロードに機密データを保存しない — ペイロードはBase64エンコードされているだけで、暗号化されていません。誰でもデコードできます。
  • 常にサーバーサイドで署名を検証する — デコードされたJWTは有効であることを意味しません。常に秘密鍵に対して署名を確認してください。
  • 有効期限を短く保つ — 長期セッションにはリフレッシュトークンを使用。短期間のアクセストークン（15〜60分）で露出を制限。
  • "none"アルゴリズムを避ける — 脆弱な実装では署名なしのトークンを受け入れるものがあります。常に特定のアルゴリズムを強制してください。
  • HTTPSのみを使用する — 傍受を防ぐために、暗号化された接続でJWTを送信してください。

本番環境でのJWTセキュリティベストプラクティス

JSON Web Tokenは認証に広く使用されていますが、不適切な実装は深刻なセキュリティ脆弱性を生みます。本番システムでJWTをデプロイする際は、以下の実戦で検証済みのプラクティスに従ってください。

トークンの保存場所

  • HttpOnly Cookie（推奨）：JWTをHttpOnly、Secure、SameSite=Strictクッキーに保存します。これによりJavaScriptからのアクセスが防止され、XSSベースのトークン盗難が排除されます。ブラウザは各リクエストでクッキーを自動的に送信します。
  • localStorage（避けるべき）：アプリやサードパーティスクリプトのXSS脆弱性があると、localStorageを読み取ってトークンを盗むことができます。本番アプリケーションでは機密トークンをlocalStorageに保存しないでください。
  • sessionStorage：タブを閉じるとクリアされるためlocalStorageよりやや安全ですが、セッション中はXSS攻撃に対して脆弱です。
  • メモリ内（SPA）：JavaScript変数にトークンを保存します。XSSに対して最も安全ですが、ページリフレッシュでトークンが失われるため、リフレッシュトークンによるサイレント再認証が必要です。

一般的なJWT脆弱性と対策

  • アルゴリズム混同攻撃：攻撃者がalgヘッダーをRS256からHS256に変更し、公開鍵でトークンに署名します。常にサーバー側でアルゴリズムを検証し、予期しないアルゴリズム値を拒否してください。
  • トークンの有効期限が長すぎる：アクセストークンは15〜30分で期限切れにすべきです。短命のアクセストークンと、サーバー側に安全に保存される長命のリフレッシュトークン（7〜30日）を組み合わせて使用します。
  • Audience/Issuer検証の欠如：あるサービスのトークンが別のサービスで受け入れられることを防ぐため、常にaud（audience）とiss（issuer）クレームを検証してください。
  • トークン失効機能なし：JWTはステートレスです — 一度発行されると期限切れまで有効です。ログアウト、パスワード変更、アカウント侵害に対応するため、トークンブロックリスト（Redis使用）を実装してください。

JWT vs セッションベース認証

JWTはステートレスAPI、マイクロサービスアーキテクチャ、サーバー側セッションストレージが実用的でないモバイルアプリに最適です。セッションベース認証は、即座の失効が必要でトークンリフレッシュロジックを管理したくない従来のサーバーレンダリングWebアプリに適しています。多くの本番システムはハイブリッドアプローチを採用しています：マイクロサービス間ではJWT、ユーザー向けフロントエンドではセッションクッキーです。

JWTに関するよくある質問

ブラウザでJWTトークンをデコードしても安全ですか？

はい、JWTのデコードは常に安全です。ヘッダーとペイロードはBase64URLエンコードされているだけで、暗号化されていないためです。トークンを持っている人なら誰でもその内容を読むことができます — これは設計上のことです。このツールはJWTをブラウザ内で完全にデコードします。トークンがサーバーに送信されることはありません。これが、JWTペイロードにパスワード、秘密鍵、機密シークレットを保存すべきではない理由でもあります。

秘密鍵なしでJWT署名を検証できますか？

いいえ。JWT署名の検証には秘密鍵（HS256などのHMACアルゴリズムの場合）または公開鍵（RS256、ES256の場合）が必要です。鍵なしでヘッダーとペイロードをデコードすることは常に可能ですが、トークンが改ざんされていないことを検証することはできません。署名検証はサーバーサイドで行う必要があります。このツールは検査のためにデコードされたトークンの内容を表示するもので、署名の有効性ではありません。

JWTトークンが予期せず期限切れになるのはなぜですか？

JWTトークンには exp クレーム — トークンの有効期限を示すUnixタイムスタンプが含まれています。現在時刻がこの値を超えると、トークンは拒否されます。これはセキュリティのための設計です。ここで exp の値を確認して、トークンがいつ期限切れになるかを理解してください。トークンの有効期限が短すぎる場合は、サーバーとクライアント間のクロックスキューを確認してください — 数分の差でも問題が発生します。NTPを使用してサーバーのクロックを同期してください。

JWTトークンの署名にはどのアルゴリズムを使用すべきですか？

ほとんどのアプリケーションでは、RS256（RSA + SHA-256）が推奨されます。非対称鍵を使用するため — 秘密鍵で署名し、公開鍵で検証するので、公開鍵を安全に共有できます。HS256（HMAC + SHA-256）はよりシンプルですが、トークンを検証するすべてのサービスと秘密鍵を共有する必要があります。「none」アルゴリズムは絶対に使用しないでください — 脆弱な実装では署名なしのトークンを受け入れるものがあり、これは重大なセキュリティ上の欠陥です。

関連開発者ツール