JWTのHeader・Payload・時刻Claimを確認する
JWTを貼り付けると、ブラウザ内でHeader・Payloadを解析し、exp・nbf・iatを端末時刻と比較できます。署名は検証しません。
JWTを解析する結論：expを秒単位のNumericDateとして変換し、検証側の現在時刻と比較する
exp=1893456000なら1970-01-01T00:00:00Zから1893456000秒後です。JWT DecoderはISO 8601、Local Time、相対時間を表示し、端末時刻では期限内か期限切れかを補助表示します。
本番でTokenを受理するのはServer側です。端末表示だけで有効と決めず、Server UTC、clock tolerance、Signature、iss・audも確認します。
Original Tokenを共有せず、Dummy Tokenで手順を確認してください。
expの単位と境界条件を確認する
RFC 7519のexpはNumericDateで、Epochからの秒です。検証時は現在時刻がexp以上なら受理してはいけません。小さなClock Skewを許容するかはLibraryとSecurity Policyに従います。
expが存在しない場合は「有効期限Claimなし」であり、永続的に有効、必ず無効のどちらともToolだけでは断定しません。
| 確認対象 | 見る内容 | 判断 |
|---|---|---|
| Raw exp | 有限のNumber | 秒か確認 |
| UTC / Local | 同一Instant | TimeZone差を区別 |
| Current | 検証時刻 | expとの大小 |
| Tolerance | 0～300秒 | Policyと一致 |
JWT Decoderへ入力して確認する手順
- Tokenを解析します。
- Claim表のexp Raw値を確認します。
- ISO・Local・相対時間を比較します。
- 端末時刻では期限内という表示を署名未検証と一緒に記録します。
「端末時刻では有効期間内」はVerify成功を意味しません。
Header・Payload・時刻Claimを順番に確認する
Headerではalg、typ、kidを読み、Payloadではiss、sub、aud、exp、nbf、iat、jtiとCustom Claimを確認します。audは文字列だけでなく配列の場合があり、Custom Claimの名前や値だけから権限を推測しません。Signature Segmentが存在しても正当性は未検証です。
| 項目 | 意味 | 確認時の注意 |
|---|---|---|
| exp | Expiration Time | NumericDateの秒。期限を過ぎると受理してはいけない |
| nbf | Not Before | この時刻より前は受理してはいけない |
| iat | Issued At | 発行時刻。単独で有効性を保証しない |
| iss / aud / sub | 発行者・受信者・主体 | 検証側が期待する値と別途照合する |
| alg / kid / typ | Algorithm・鍵ID・Type | Token内の指定だけを信頼して鍵やAlgorithmを決めない |
問題が解決しない場合の切り分け
日時が極端に未来または過去なら、秒とMilliseconds、StringとNumber、TimeZone表示を確認します。
APIが期限切れを返す場合は、Tokenを判定したServer時計とLog時刻を優先し、Clientの見た目だけでClock Skewを決めません。
- 10桁前後の秒か
- Date.now()をそのまま入れていないか
- Server UTCを確認したか
- Refresh TokenとAccess Tokenを混同していないか
現行のJWT Decoderで確認できる範囲
DevelopToolsのJWT Decoderは、入力したTokenをサーバーへ送信せず、ブラウザ内でCompact JWS形式の3セグメントを解析します。Bearer接頭辞と表示上の改行を整理し、Header・PayloadをBase64URLからUTF-8へ戻してJSON Objectとして表示します。Signatureは存在・Byte数・Segment文字列を確認できますが、鍵を使った署名検証は行いません。
| 確認対象 | 現行ツールの動作 |
|---|---|
| 入力 | Raw Token、Bearer付きToken、折り返されたTokenを解析 |
| 構造 | Header.Payload.Signatureの3セグメントを分離し、5セグメントのJWEは未対応として表示 |
| Decode | Base64URLの-・_と省略Paddingを扱い、UTF-8とJSON Objectを検査 |
| Claims | iss、sub、aud、exp、nbf、iat、jtiを値と説明付きで表示 |
| 時刻 | exp・nbf・iatをISO 8601、利用者のLocal Time、現在からの相対時間で表示 |
| 判定 | 端末時刻と時計ずれ許容秒数を基に、期限切れ・利用開始前・未来のiat等を補助表示 |
| 出力 | Token、整形済みHeader、整形済みPayloadをClipboardへCopy |
HS256・RS256等の署名検証、秘密鍵・公開鍵・JWK・JWKSの読込、IssuerやAudienceの期待値検証、失効・Scope・権限確認、JWEの復号は行いません。「端末時刻では有効期間内」という表示も、Token全体が有効または安全という保証ではありません。
Decode・Verify・Validateを分けて扱う
DecodeはBase64URL表現を読める形へ戻す処理です。VerifyはSignature、信頼する鍵、許可したAlgorithmを使って改ざんされていないことを確認する処理です。Validateはさらにexp・nbf、Issuer、Audience、用途、失効状態等をApplicationのPolicyと照合します。Decodeに成功してもVerifyやValidateに成功したことにはなりません。
一般的な3セグメントのJWSではHeaderとPayloadは暗号化されていません。Tokenを入手した人は内容を読めるため、Password、Secret、不要な個人情報をPayloadへ入れません。実Tokenを記事、Issue、Chat、URL Query、Screenshotへ掲載せず、検証にはDummy Tokenを使います。
現行ツールの表示は署名未検証です。認証・認可、本番障害の最終判断、Tokenの安全性保証には使用せず、利用中の認証LibraryとIdentity Providerの公式手順で検証してください。
JWTとJOSEの仕様は一次資料で確認する
ClaimとNumericDateはRFC 7519、JWSのCompact SerializationとBase64URLはRFC 7515、JWEはRFC 7516、Base64URL AlphabetはRFC 4648、JWTのSecurity Best Current PracticeはRFC 8725を基準にします。Bearer Tokenの利用方法はRFC 6750を確認します。
具体例：expをUTCと日本時間で比較する
Dummy Payloadのexpを解析し、ISO 8601とBrowserのLocal Timeを並べます。
同じInstantが異なるTimeZone表記で表示され、現在からの残り時間または経過時間を確認できます。
- Dummy JWTを解析する
- expのRaw値を控える
- ISOとLocalを比較する
- 境界時刻前後で新Tokenを試す
本番Tokenの値を記事やBug Reportへ貼らず、必要なら日時だけを安全に転記してください。
よくある質問
- JWTをデコードできればTokenは有効ですか？
- いいえ。Decodeは内容を読む処理です。認証に使えるかは、信頼する鍵による署名検証、許可Algorithm、iss・aud・exp・nbf等の検証、失効やApplication Policyを含めて判断します。
- JWTのPayloadは暗号化されていますか？
- 一般的な3セグメントのJWSでは暗号化されず、Base64URLで表現されているだけです。機密情報を保存する場所として扱わないでください。