JWT デコード・HMAC 検証・トークン生成

JWT の検査は認証ではありません

デコードしたクレームは読める形の Base64URL データであり、トークンが信頼できる証明ではありません。アルゴリズム、有効期限、想定された発行者と対象を確認し、アプリで受け入れる前に信頼できる鍵や秘密鍵で署名を検証してください。

JWT を検査・検証する方法

このページはコンパクト形式の JWT をヘッダー・ペイロード・署名に分解し、デコードしたクレームを表示します。HMAC 署名のトークンなら、シークレットを入力して署名を検証できます。入力したペイロードから有効期限の短い HS256・HS384・HS512 トークンを生成することもできます。

デコードと検証が別の手順になっているのは意図的です。JWT のペイロードは鍵なしで誰でも読めますし、署名が有効でも「その鍵で署名された」ことしか分かりません。期限切れかどうか、自分のサービス向けに発行されたか、何を許可するかは示しません。

トークン欄に header.payload.signature 形式の JWT を貼り付け、「トークンを検査」を押します。動作するサンプルは「サンプルを読み込む」で作成できます。
デコードされたヘッダー（アルゴリズム・type・kid）とペイロードを確認します。その上のクレーム欄にアルゴリズム・有効期限・有効開始日時・発行者がまとまって表示されます。
HMAC トークンを検証するには、アルゴリズムで HS256・HS384・HS512 を選び、共有シークレットを入力して「署名を検証」を押します。
テスト用トークンを作るには、アルゴリズムを選び、Payload に JSON オブジェクトを貼り、必要なら「有効期限（分）」と iat クレームを設定して「ローカルで JWT を生成」を押します。
「ヘッダーをコピー」「ペイロードをコピー」でデコード結果を取得し、「生成したトークンを検査」で生成直後のトークンを検査欄に戻せます。

JWT の構造・アルゴリズム・クレーム

3 つの部分に何が入っているか

ヘッダーは Base64URL で符号化した JSON で、通常は alg と typ、場合によっては使用する鍵を示す kid を含みます。ペイロードはクレームの集合で、iss・sub・aud・exp・nbf・iat・jti などの登録クレームと発行者が追加した独自クレームからなります。署名は base64url(header) + "." + base64url(payload) という ASCII 文字列に鍵を使ってアルゴリズムを適用した結果です。

Base64URL は標準 Base64 の + と / を - と _ に置き換え、パディングを省いたものです。だからトークンはエスケープなしで URL・Cookie・Authorization ヘッダーに載せられ、逆に手作業で組み直すと署名が壊れます。

このページが検証できるアルゴリズム

HMAC 系の HS256・HS384・HS512 だけです。共有シークレットがあれば再計算できるためです。RS256・PS256・ES256・EdDSA は秘密鍵で署名し公開鍵で検証する方式なので、ここではデコードのみ可能で検証はできません。検証には発行者の公開 JWK が必要です。RS256 のトークンでは「署名を検証」ボタンが無効になり、その旨が表示されます。

alg が none のトークンは赤で警告します。決して受け入れてはいけないもので、検証側は許可リストで確認せずにトークンが宣言するアルゴリズムを信用すべきではありません。RS256 を HS256 に置き換え、公開鍵を HMAC のシークレットのように使って署名するのは、ずさんなライブラリに対する有名な攻撃です。

受け入れる前に確認すべきクレーム

exp は未来、nbf は過去である必要があり、どちらも Unix エポックからの秒数で、マシン間の時計差を少し許容します。iat は未来ではなく妥当な時刻であるべきです。iss と aud は自分のサービスと一致しなければならず、別のアプリ向けに発行されたトークンを受け入れてしまいます。

署名の確認は認可ではありません。ロール・スコープ・テナント識別子は独自クレームに入り、JWT のクレームは署名されるだけで暗号化はされません。トークンを持つ相手に見せられない内容をペイロードに入れないでください。

JWT の署名とクレームに関する質問

このページにトークンを貼り付けても安全ですか？

デコードと HMAC 検証はブラウザー内で実行されるため、トークンは送信されません。それでも使い捨てのトークンで試すのが安全な習慣です。本番のリフレッシュトークンや長期間有効な資格情報は、このページに限らずどの Web ページにも貼るべきではありません。

RS256 や ES256 のトークンで検証が失敗するのはなぜですか？

これらの方式は非対称で、このページは HMAC 署名しか再計算できません。デコードとクレームの確認はできますが、検証には発行者の公開鍵と JWA 対応ライブラリが必要で、共有シークレットしか持たないブラウザー上のページでは正しく行えません。

署名が無効と表示されます。どういう意味ですか？

シークレットが違うか、選んだアルゴリズムがヘッダーのものと一致しないか、署名後にトークンの文字列が変わったかのいずれかです。ペイロードを編集して整形し直し手で再エンコードしても同じ結果になります。署名は元のバイト列そのものを対象にしているためです。

鍵がないのにペイロードを読めるのはなぜですか？

JWT は署名されるだけで暗号化されないからです。Base64URL は符号化であり、トークンを持っていれば鍵なしでヘッダーもペイロードもデコードできます。クレーム自体が機密なら、受信者向けに内容を暗号化する JWE を使ってください。

JWT・JWS・JWE は何が違いますか？

JWT はクレームの集合、つまりデータです。JWS は署名されたシリアライズで、このページが検査する 3 分割のコンパクトトークンを作ります。JWE は暗号化されたシリアライズで、鍵なしではペイロードを読めず、構造は 3 つではなく 5 つの部分になります。

生成したテスト用トークンの有効期限はどれくらいにすべきですか？

時間ではなく分単位です。「有効期限（分）」を小さくしておけば、漏れたテスト用トークンがすぐ無効になります。このページは入力したシークレットでローカルに署名するため、そのシークレットを共有するシステムでしか通用しない点も覚えておいてください。

JWT 検証 & 生成