JWTデコーダー
ブラウザ内で動作し、何もアップロードされません
JSON Web Tokenのヘッダーとクレームを読み、有効期限を確認し、シークレットや公開鍵で署名を検証します。
Token
Verify signature
Paste a token to check its signature against a secret or public key.
No token yet
JWTとは？
JSON Web Token（JWT）は、2者の間でクレームをやり取りするための、コンパクトで署名付きの形式です。多くの場合、認証サーバーからAPIへ渡されます。ドットでつながった3つのBase64url文字列 header.payload.signature でできており、APIは通常 Authorization: Bearer <token> ヘッダーで受け取ります。
ヘッダーには署名の方式が書かれています。たとえば共有シークレットを使うHMACなら "alg": "HS256"、RSAの鍵ペアなら RS256 です。ペイロードにはクレームが入っています。sub（トークンの対象者）、iat（発行日時）、exp（有効期限）といった標準のクレームに加えて、ロールやスコープなど発行者が追加したものです。
トークンを信頼できるものにしているのが署名です。発行者が自分の鍵でヘッダーとペイロードから署名を計算するため、ペイロードを1文字でも変えると署名が合わなくなります。ペイロードはエンコードされているだけで暗号化されていません。トークンを持っている人なら誰でもすべてのクレームを読めるので、秘密情報は絶対に入れず、トークン自体も有効期限までパスワードと同じように扱ってください。
使い方
- 1トークンを Token パネルに貼り付けるか、Examples から選びます。
Bearerの接頭辞、Authorization:というヘッダー名、引用符、改行は無視され、何を無視したかはパネルのヘッダーに表示されます。 - 2トークンの中で、ヘッダー、ペイロード、署名が色分けされます。Payload と Header は各パートをJSONで表示します。Claims は各クレームとその意味を一覧にし、
iat、nbf、expをあなたのタイムゾーンの日時と、どれくらい前・後かで表示します。 - 3ステータスバーには、アルゴリズム、トークンの有効期限（または期限切れになった日時）、署名を検証したかどうかが表示されます。
alg: noneやexpがないといった警告は、Claims の一番上に表示されます。 - 4署名を検証するには、共有シークレットを入力するか（HS256、HS384、HS512。シークレットがエンコードされている場合は Base64 に切り替えます）、発行者の公開鍵（RS*、PS*、ES*、EdDSA）をPEM、X.509証明書、JWK、JWKセットのいずれかで貼り付けます。結果は入力に合わせて表示されます。
- 5トークンをデコードできない場合は、どのパートのどの文字が問題かがメッセージに表示されます。F8でその文字を選択できます。
トラブルシューティング
- このトークンは5つのパートからなる、暗号化されたJWEです
- IDプロバイダーの中には、暗号化されたトークン（JWE）を発行するものがあります。そのペイロードは受信者の秘密鍵でしか読めないため、その鍵がなければどのデコーダーでも表示できません。
+は標準のBase64の文字です。JWTはBase64urlを使います- トークンが標準のBase64で再エンコードされたか、手作業で組み立てられています。JWTの各パートは
+と/の代わりに-と_を使い、=のパディングはありません。 - 署名がこのシークレットと一致しません
- シークレットが発行者の使っているものと、大文字・小文字や末尾の空白まで完全に同じか確認してください。また、Base64で保存されていないかも確認し、そうであればシークレットの形式を Base64 に切り替えてください。
- これはPKCS#1形式のRSA鍵（BEGIN RSA PUBLIC KEY）です
- ブラウザがインポートできるのはSubjectPublicKeyInfo形式の鍵だけです。
openssl rsa -RSAPublicKey_in -in key.pem -puboutで変換するか、代わりに発行者のJWKSエンドポイントにあるJWKを貼り付けてください。 - 鍵セットにこのkidの鍵がありません
- 発行者は鍵をローテーションします。発行者の
jwks_uriから最新のJWKセットを取得して貼り付け直してください。ツールは、kidがトークンのヘッダーと一致する鍵を選びます。
よくある質問
本物のトークンやシークレットをここに貼り付けても安全ですか？
デコードと署名の検証はブラウザ内でWeb Cryptoを使って行われ、どこにも送信されません。トークンは消去するかタブを閉じるまでこのタブのsession storageに保存されるので、再読み込みしても消えません。検証に使うシークレットや鍵は保存されず、トークンがリンクに入ることもありません。それでも、有効なトークンは期限が切れるまでアクセス権を与えるので、テスト用や期限切れのトークンを使うことをおすすめします。また、本番環境の署名用シークレットは、自分で管理していないWebサイトには決して貼り付けないでください。
"Signature verified" とはどういう意味ですか？
ヘッダーとペイロードが、そのシークレット、または指定した公開鍵に対応する秘密鍵で署名されたという意味です。トークンを受け入れてよいという意味ではありません。APIでは exp、nbf、発行者（iss）、オーディエンス（aud）も確認し、どのアルゴリズムを受け付けるかを決める必要があります。
alg none はなぜ危険なのですか？
"alg": "none" のトークンには署名がないため、誰でも好きなクレームを入れたトークンを作れます。これを誤って受け入れるライブラリがあると、攻撃者がトークンを偽造できてしまいます。サーバーは署名のないトークンを拒否すべきです。
iat、nbf、exp はどんな形式ですか？
1970年1月1日UTCからの秒数（Unix時間）です。13桁の値はミリ秒で、トークン発行者によくあるバグです。ツールはこれを警告します。Unixタイムスタンプ変換ツールを使えば、どの値も日時に変換できます。
正常にデコードできるのに、トークンが拒否されるのはなぜですか？
よくある原因は、別の鍵による署名、aud や iss の誤り、nbf より前または exp より後の使用、サーバー間の時刻のずれです。APIのエラーレスポンスを読み、これらのクレームと照らし合わせてください。