JWT デコーダー
JWT のヘッダー、ペイロード、有効期限を確認します。
このツールについて
JSON Web Token をデコードして、ヘッダーとクレームを読み取ります。exp、iat、nbf などのタイムスタンプは読みやすい日時で表示され、トークンが期限切れかどうかもひと目でわかります。署名は検証されません。
使い方
- JSON Web Token を貼り付けます。先頭の「Bearer 」は自動的に取り除かれます。
- デコードされたヘッダーとペイロードを確認します。
- ステータス表示と時刻のクレームで、トークンの発行日時と有効期限を確認します。
よくある質問
- 署名は検証されますか？
- いいえ。トークンをデコードするだけです。検証には秘密鍵または公開鍵が必要で、サーバー側で行うべきです。デコードできたというだけでトークンを信用してはいけません。
- 本物のトークンをここに貼り付けても安全ですか？
- デコードはすべてブラウザー内で行われ、トークンがどこかに送信されることはありません。それでも、本番環境のトークンはパスワードと同様に扱い、できるだけ期限切れのトークンやテスト用のトークンを使ってください。
- exp、iat、nbf は何を意味しますか？
- exp はトークンの有効期限、iat は発行日時、nbf はそれより前には受け付けてはならない日時です。3 つとも秒単位の Unix タイムスタンプです。
- JWT の中身は誰でも読めますか？
- はい。ヘッダーとペイロードは Base64url エンコードされているだけで、暗号化されていません。JWT のペイロードに秘密情報や機微な個人データを入れないでください。
- トークンが 3 つではなく 5 つの部分に分かれているのはなぜですか？
- ドットで区切られた 5 つの部分を持つトークンは JWE で、RFC 7516 で定義されている暗号化された JSON Web Token です。復号鍵がないとペイロードを読めないため、このデコーダーはエラーを報告します。部分が 2 つしかないトークンは、たいていコピー時に途中で切れています。署名のないトークンでも、末尾のドットは残るためです。
- JWT ヘッダーの kid とは？
- kid はキー ID です。発行者が JWKS ドキュメントなどで複数の鍵を公開している場合に、どの鍵を使うべきかを検証側に伝えます。これにより鍵のローテーションが可能になります。新しいトークンは新しい鍵で署名され、古い鍵で署名されたトークンは期限切れになるまで有効なままです。
- JWT のペイロードを編集してもそのまま使えますか？
- ペイロードを変更して再エンコードすることはできますが、署名が一致しなくなるため、正しく設定されたサーバーはそのトークンを拒否します。編集したトークンが受け付けられるなら、そのサーバーは署名を検証していません。これは深刻なセキュリティホールなので、すぐに報告するか修正すべきです。
JWT とは？ 構造と仕組み
RFC 7519 で定義されている JSON Web Token は、ドットで区切られた 3 つの部分（ヘッダー、ペイロード、署名）からなるコンパクトな文字列です。ヘッダーには、HS256 や RS256 などの alg の値で、トークンの署名方法が示されます。ペイロードにはクレームが入ります。トークンが誰についてのものか（sub）、誰が発行したか（iss）、誰に向けたものか（aud）、いつ期限切れになるか（exp）です。どちらの部分も base64url でエンコードされた JSON です。
3 つ目の部分は署名で、最初の 2 つの部分に対して、共有シークレットまたは秘密鍵を使って計算されます。ヘッダーは波かっことダブルクォートで始まる JSON なので、ほぼすべての JWT は eyJ で始まります。これを手がかりに、ログやリクエストヘッダーの中の JWT を見つけられます。この JWT デコーダーにトークンを貼り付けると、ヘッダーとペイロードが整形されて表示され、時刻のクレームは日時として表示されます。
JWT がデコードできるのに拒否されるのはなぜですか？
問題なくデコードできるトークンでも、拒否されることはあります。たいていは 401 が返されます。最もよくある原因は有効期限切れなので、ステータス表示で exp がすでに過去になっていないか確認してください。exp は秒単位であることに注意しましょう。JavaScript のミリ秒の時刻と比較するバックエンドは誤った判定をします。サーバー間の時計のずれも影響するため、ほとんどのライブラリは多少の猶予を設けています。
時刻が正しく見える場合は、クレームをサーバーが期待する値と比較してください。API と一致しない aud、想定外の iss、ステージングの ID プロバイダーが発行したトークンを本番環境に送った場合などは、どれも検証に失敗します。署名の検証は、鍵が間違っている、トークンが改変された、ヘッダーの alg がサーバーで受け付けられないもの、のいずれかの場合に失敗します。このデコーダーは署名を検証しないため、どれに当てはまるかは判断できません。
HS256 と RS256 の違い: JWT のアルゴリズムはどちらを使うべき？
HS256 は、HMAC-SHA256 と 1 つの共有シークレットでトークンに署名します。トークンを検証するすべてのサービスに同じシークレットが必要で、そのシークレットがあれば新しいトークンも作成できてしまいます。単一のバックエンドなら問題ありませんが、多くのサービスにまたがる場合は危険です。RS256（RSA）や ES256（ECDSA）は鍵ペアを使います。発行者は秘密鍵で署名し、それ以外の全員は公開鍵で検証します。公開鍵は JWKS エンドポイントで公開されることがよくあります。
どちらを選ぶにしても、ヘッダーの alg フィールドを信用するのではなく、検証側で許可するアルゴリズムを固定してください。alg が none に設定されたトークンには署名がまったくないため、必ず拒否しなければなりません。exp は日単位ではなく分単位で短く設定し、長いセッションにはリフレッシュトークンを使いましょう。ここではヘッダーのパネルで alg と kid を確認でき、タイムスタンプは Unix タイムスタンプ変換ツールで確認できます。
うまく動かない、または結果がおかしいですか？ このツールの問題を報告