しくみ
JSON Web Tokenはドット区切りの3つのBase64URL部分（ヘッダー、ペイロード、署名）で構成されます。デコードは前の2つを読むだけなのでオフラインで動き、発行者を証明しません。発行者の鍵で署名を確認して初めて真正性が分かり、有効な署名でも期限切れのトークンは拒否すべきです。
header.payload.signature → JSON＋日付＋署名確認
使う鍵の選び方
- HS256 / HS384 / HS512: 共通鍵のテキストを貼り付けます。持っている人は署名も検証もできます。
- RS256–RS512 / PS256–PS512: PEM（SPKI）またはJWK形式の公開鍵を貼り付けます。秘密鍵は発行者が持ちます。
- ES256 / ES384 / ES512: PEMまたはJWK形式のEC公開鍵を貼り付けます。トークン内の生R‖S署名は自動で変換されます。
- EdDSA: 32バイトの公開鍵をBase64URLまたは16進数で貼り付けます。
- none: 署名がまったくありません。このようなトークンは絶対に信用してはいけません。
活用のヒント
- exp、iat、nbfは日付で表示し、それぞれ経過済みかどうかも示します。
- 本物のアクセストークンを貼り付けても通信面では安全ですが、持っている人は使えてしまうため、有効期間の短いテスト用トークンを使ってください。
- すべてブラウザ内で動き、アップロードしません。
計算の基準と出典
- JSON Web Token（JWT）：RFC 7519、JWS署名：RFC 7515
- アルゴリズム（HS/RS/PS/ES）：RFC 7518、EdDSA：RFC 8032
- Base64URL：RFC 4648
最終確認 2026年10月12日
よくある質問
デコードで何が証明できますか?
真正性は何も証明できません。デコードは誰でも偽造できるヘッダーとペイロードを読むだけです。発行者の鍵で署名を確認して初めて本物と分かります。
検証できるアルゴリズムは?
共通鍵のHMAC（HS256/384/512）、PEM・JWK公開鍵のRSA（RS/PS）とECDSA（ES256/384/512）、生公開鍵のEdDSA（Ed25519）を検証します。algがnoneのトークンには署名がなく、絶対に信用してはいけません。
有効なトークンがサーバーに拒否されるのはなぜ?
多いのはexpの期限切れ、audience・issuerの不一致、署名側とサーバーの時計のずれです。このページでは日付クレームを1つずつ表示するので、どれが原因か分かります。
本物のトークンを貼り付けても安全ですか?
このページは完全オフラインで何も送信しませんが、トークンを持つ人は期限まで使えます。本番のアクセストークンより、有効期間の短いテスト用トークンを使ってください。