JWT デコーダー

JWT デコーダーについて

この無料の JWT デコーダーは、JSON Web Token を読み取り、そのヘッダーとペイロードを整形した JSON として表示します。発行時刻と有効期限は読みやすい日付に変換されます。

デコードはお使いのブラウザー内で行われ、トークンがアップロードされることはありません。これは些細な点ではありません。JWT は通常、有効な認証情報です。どこかへ送信するウェブサイトに貼り付ければ、そのトークンが持つあらゆるアクセス権を渡すことになります。

このツールはトークンをデコードします。署名の検証は行いません — その違いがなぜ重要なのかは以下で説明します。

トークンの3つの部分

JWT は、ピリオドで区切られた3つの Base64url の塊です。

xxxxx.yyyyy.zzzzz

ヘッダー — どのアルゴリズムでトークンが署名されたか、そして種類は何かを示します。通常は alg と typ の2つのフィールドです。

ペイロード — クレームです。トークンが誰に関するものか、誰が発行したか、いつ期限が切れるか、そしてアプリケーションが入れたその他の情報（ユーザー ID、メールアドレス、ロール、権限、テナントなど）が含まれます。

署名 — 最初の2つの部分に対する暗号学的なチェックで、秘密鍵または共有の秘密を使って作られます。発行後にトークンが変更されていないことを証明します。

理解すべき本質は、最初の2つの部分は暗号化されていないということです。単にエンコードされているだけで、誰でも読めます。このページにトークンを貼り付ければ、中身が即座に表示されます。Base64url はデータを URL やヘッダーに安全に入れるための方法であって、隠すための方法ではありません。

トークンに入れる内容にとっての意味

ペイロードはトークンを持つ誰にでも見えるため、規則は直接導かれます。JWT には決して秘密の情報を入れないでください。

ペイロードに入れてはいけないもの: パスワード、API キー、クレジットカード情報、国民識別番号、医療情報、プライバシー規制の対象となるあらゆる情報。これらはすべて、ユーザー本人にも、リクエストを記録するあらゆる仕組みにも、トークンを入手した誰にでも読まれます。

入れてよいもの: ユーザー ID、ロール、有効期限、発行者、対象者 — 受け取る側のシステムに見られることを前提とした識別子とクレームです。

署名が守るのは完全性であって、機密性ではありません。誰もトークンを変更していないことは保証しますが、読まれることを防ぐ働きはまったくありません。

デコードは検証ではない

これは実際のセキュリティ上のバグを引き起こす区別なので、正確に述べる価値があります。

デコードは Base64url を展開して JSON を表示します。鍵は不要で、誰にでもでき、トークンが本物かどうかについては何ひとつ証明しません。

検証は、秘密鍵または公開鍵を使って署名を再計算し、一致するかを確認します。トークンが本当に名乗っている発行者によって発行され、改ざんされていないと分かるのは、これだけです。

トークンが完璧にデコードできても、完全な偽造である場合があります。誰でも "role": "admin" と書かれた JWT を作れますし、それはここで問題なく表示されます — 表示しているだけだからです。

このツールは意図的に検証を行いません。それが安全な選択です。検証には署名用の秘密鍵が必要であり、署名用の秘密鍵をウェブページに貼り付けるのは、トークンを貼り付けるよりはるかに危険です。検証は、ご自分のサーバーで、ご自分の鍵を使い、適切なライブラリで行うべきものです。

この誤りの歴史的な形が alg: none 攻撃です。初期の JWT ライブラリは、アルゴリズムを使っていないと主張するヘッダーをそのまま受け入れ、未検証のままトークンを通しました。攻撃者はペイロードを書き換え、alg を none に設定して侵入できました。現代のライブラリはこれを拒否しますが、ヘッダーの言い分を信じるのではなく、期待するアルゴリズムを常に固定すべき理由がここにあります。

標準クレームの読み方

ペイロード内の短いフィールド名の多くは、意味が定められた登録済みクレームです。

exp — 有効期限。これを過ぎたトークンは拒否されるべきです。
iat — issued at、発行時刻。いつ作成されたか。
nbf — not before。この時刻までトークンは無効です。
sub — サブジェクト（主体）。通常はユーザー ID です。
iss — 発行者。トークンを作成した主体です。
aud — 対象者。どのサービス向けかを示します。
jti — トークン ID。失効リストで使われます。

exp、iat、nbf は Unix タイムスタンプ、つまり1970年1月1日からの秒数です。だからこそ意味のない10桁の数字に見えます。このツールはこれらを読みやすい日付に変換します。多くの場合、ここへ来た理由である「*このトークンは期限切れか？*」という問いに最も早く答える方法です。

使い方

JWT を貼り付けます（xxxxx.yyyyy.zzzzz の文字列）
下に表示されるデコード済みのヘッダーとペイロードを読みます
必要ならどちらの部分もコピーできます

知っておくとよいこと

トークンはパスワードと同じように扱ってください。 有効なうちは、持っている人が誰でもそのユーザーとして振る舞えます。アップロードするツールに有効なトークンを貼り付けないでください。チケットやチャットに投稿するのも避けてください。
JWT は失効させにくいものです。 期限が切れるまで有効なので、盗まれたトークンはブロックリストを運用していない限りその間ずっと使えます。有効期限を短くすることが重要な理由です。
Bearer はトークンの一部ではありません。 デコードする前に Authorization ヘッダーからこの接頭辞を取り除いてください。
Base64url は標準の Base64 ではありません。 + と / の代わりに - と _ を使い、通常は = のパディングを省きます。そのため JWT の一部が普通の Base64 デコーダーで失敗することがあります。
時計のずれが分かりにくい失敗を招きます。 自分には有効に見えるトークンが、1〜2分ずれた時計を持つサーバーに拒否されることがあります。
JWT はセッションではありません。 クレームを自ら持ち運ぶため、ユーザーのロールを変更しても、トークンの期限が切れるまで反映されません。

よくある質問

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

いいえ。ヘッダーとペイロードは Base64url でエンコードされており、URL や HTTP ヘッダーに安全に入れられるようになっていますが、内容を隠す働きはまったくありません。このページが示すとおり、トークンを持つ人は中のすべてのクレームを読めます。署名はトークンが変更されるのを防ぐものであって、読まれるのを防ぐものではありません。

このツールは署名を検証しますか？

いいえ、意図的に行いません。検証には署名用の秘密鍵または公開鍵が必要で、署名用の秘密鍵をウェブページに貼り付けるのは、トークンを貼り付けるよりかなり危険です。検証は適切なライブラリを使ってご自分のサーバーで行うべきものです。このツールはデコードして中身を表示します。デバッグで必要なのはこれです。

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

ここでは安全です。デコードは完全にブラウザー内で行われ、何も送信されないため、インターネットを切断しても動作します。ただし、ツール全般には注意してください。有効な JWT は機能する認証情報であり、それをサーバーへ送るサイトは、そのトークンが与えるアクセス権をそのまま受け取ったことになります。

トークンが期限切れかどうかはどう分かりますか？

exp クレームを見てください。秒単位の Unix タイムスタンプです。このツールはそれを読みやすい日付に変換し、その時刻を過ぎているかどうかを直接示します。自分には有効に見えるのにサーバーが拒否する場合は、時計のずれを確認してください。マシン間で1〜2分違うだけで十分に起こります。

sub、iss、aud、iat はどういう意味ですか？

いずれも標準の意味を持つ登録済みクレームです。sub はサブジェクト、通常はユーザー ID。iss はトークンを作成した発行者。aud は想定される対象者、つまりどのサービスが受け入れるべきかを示します。iat は発行時刻です。exp と nbf と合わせて、誰が・どこで・いつを表します。

普通の Base64 デコーダーで JWT が失敗するのはなぜですか？

JWT が Base64url を使っているからです。これは + を - に、/ を _ に置き換え、通常は = のパディングを取り除く変種です。この置き換えは、値を URL の中でも安全に扱えるようにするためのものです。文字を元に戻せば、標準の Base64 ツールでデコードできます。

JWT のペイロードを編集できますか？

テキストを変更することはできますが、その結果は正しく実装されたサーバーであればすべて拒否します。署名が変更後の内容と一致しなくなるからです。署名はまさにそのためにあります。トークンは署名するサービスによって再発行されるものであり、手作業で編集するものではありません。