RevealTheme logo

JWTデコーダー

JSON Web Token(JWT)を瞬時にデコードします。お使いのブラウザ内で実行されるため、トークンがデバイスの外に出ることはなく、本番環境のシークレットでも安全に利用できます。

このツールの使い方

  1. 1

    入力欄にJWTを貼り付けます。

  2. 2

    「デコード」をクリックします。ヘッダーとペイロードが解析され、表示されます。

  3. 3

    アルゴリズム、クレーム(claims)、有効期限、発行者を確認します。

JWTとは何か、そしてどのように機能するのか?

JSON Web Token(JWT、RFC 7519で定義)とは、ユーザーに関する一連のクレーム(claims)を、コンパクトでURLセーフな形式で表現する方法であり、それらのクレームが改ざんされていないことを暗号的に証明します。JWTは、最新のWebスタックの大半で認証を支えています。ログインすると、サーバーはあなたのユーザーIDと権限を含むJWTを作成し、シークレットキーで署名して返します。ブラウザはそのトークンを保存し(通常はlocalStorageまたはCookie内)、以降のすべてのリクエストのAuthorizationヘッダーに含めます。サーバーはリクエストごとに署名を検証します。署名が有効ならトークンのクレームは信頼され、改ざんされていれば署名が破綻してリクエストは拒否されます。JWTはBase64URLでエンコードされピリオドで区切られた3つの部分から成ります。ヘッダーは署名アルゴリズムを宣言します(HMAC-SHA256の場合はHS256、RSAの場合はRS256、ECDSAの場合はES256、署名なしトークンの場合はnone。これは危険であり拒否すべきです)。ペイロード(payload)には実際のクレームが含まれます('sub'は主体、'exp'は有効期限、'iat'は発行日時といった標準クレームに加え、アプリケーションが定義する任意のカスタムクレーム)。署名は、ヘッダーとペイロードが、シークレットを保有する者によって署名されたことの証明です。このデコーダーは最初の2つの部分を明らかにします。これらは公開情報です。署名はキーがなければ検証できません。だからこそ、あらゆるJWTデコーダーは検証なしでクレームを表示するのです。

よくある活用例

  • クライアントが送信したJWTをデコードして認証の問題をデバッグする。どんなクレームを含み、誰が発行し、いつ失効するかを正確に確認できます。

  • APIゲートウェイのJWT(AWS Cognito、Auth0、Okta)を調べ、下流サービスのクレーム構造を把握する。

  • カスタムクレーム(組織ID、ロール、機能フラグ)がトークン発行コードで正しく設定されているか検証する。

  • 更新前後のトークンを比較し、有効期限が延長されたことを確認する。

  • トークンのアルゴリズムを監査する。本番環境ではRS256またはES256が使われ、決して'none'が使われていないことを確認する。

  • サーバーログのbase64urlペイロードを、読みやすいクレームに変換する。

よくある質問

本番環境のJWTで使っても安全ですか?
はい。デコードはローカルのJavaScriptによって完全にブラウザ内で行われます。トークンが当サイトのサーバーに届くことも、ログに記録されることもありません。デコード中にDevTools→「ネットワーク」タブを開けば確認できます。外向きのリクエストは一切発生しません。とはいえ、JWTは資格情報として扱ってください。デコーダーがどこで実行されるかに関わらず、URL、スクリーンショット、共有ドキュメントに貼り付けないでください。
これは署名を検証しますか?
いいえ。署名の検証には、シークレット(HS256の場合)または公開鍵(RS256/ES256/PS256の場合)が必要です。JWTを検証するためにシークレットの入力を求めるWebツールは、セキュリティ上の危険信号です。署名キーを見知らぬ相手に送ることになるからです。署名はサーバー上で、または自分で管理するライブラリ(jose、jsonwebtoken)で検証してください。
JWTが失効していたらどうなりますか?
失効してもデコードは妨げられません。'exp'クレームはペイロード内の単なるデータの一片です。デコードされたペイロード内で'exp'を探してください。これはUnixタイムスタンプ(1970年からの秒数)です。当サイトのタイムスタンプ変換ツールで変換すれば、お使いのタイムゾーンでの有効期限を確認できます。'exp'がすでに過ぎている場合、デコーダーはまだ読み取れても、規格に準拠したあらゆる検証器はそのトークンを拒否します。
JWTは暗号化できますか?
はい。それはJWE(JSON Web Encryption、RFC 7516)と呼ばれます。このツールが扱うのはJWS(JSON Web Signature、一般的なケース)で、ペイロードは署名されていますが内容は見える状態です。JWEトークンはピリオドで区切られた部分が3つではなく5つあり、復号には受信者の秘密鍵が必要です。お使いのトークンが5つの部分から成る場合は、JWEに対応したツールが必要です。
'alg': 'none'とはどういう意味で、危険なのですか?
'none'は署名がないことを意味します。トークンは署名されておらず、誰でも任意のクレームを偽造できます。本番システムは'alg: none'のトークンを明示的に拒否しなければなりません。一部のライブラリは既定でこれらを受け入れてしまいます(よく知られたCVEの一種です)。アプリケーションが想定するアルゴリズムだけを常に許可してください。
なぜセッションCookieではなくJWTを使うのですか?
JWTはステートレスです。サーバーはセッションを参照する必要がなく、トークン自体がユーザーの識別情報と権限を保持しています。これによりJWTは分散システムやAPIに最適です。セッションCookieはステートフルで(サーバー側のセッションストレージが必要)、無効化が容易です(セッションを削除するだけです)。トレードオフとして、JWTはスケールしやすい一方、トークンが失効するまで「ユーザーをログアウトさせる」ことはできません。
JWTの標準クレームには何がありますか?
RFC 7519は次を定義しています。iss(発行者)、sub(主体、通常はユーザーID)、aud(対象者)、exp(有効期限)、nbf(有効化日時)、iat(発行日時)、jti(JWTのID)。これら以外に、アプリケーションは'roles'、'permissions'、'tenant_id'のようなカスタムクレームを追加します。カスタムクレームは小さく保ってください。JWTはすべてのリクエストのヘッダーで運ばれ、帯域消費を増やします。

関連ツール