クレームと有効期限確認のためのJWTデコーダー

ヘッダーとペイロードをデコードし、expとiatを把握し、認証を壊しがちなクレームに注目してBearerトークンをすばやく確認します。

これは実際の認証障害をデバッグするためのガイドです。トークンをデコードし、クレームを読み、このツールで証明できること/できないことを正確に見極めてください。

こんなときに使う

APIがBearerトークンを拒否し、再試行前にヘッダー、クレーム、タイムスタンプを確認する必要がある。

まず確認すること

有効そうに見えるトークンでも失敗する理由は、多くの場合alg、exp、aud、scope、subを見れば分かります。

よくある落とし穴

デコードで分かるのはトークンが何を示しているかであり、署名が有効または信頼できることの証明ではありません。

使い方の例

生のトークンだけを貼り付ける

Authorizationヘッダーをコピーした場合は、デコーダーに貼り付ける前にBearerプレフィックスを削除してください。

Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

期限切れトークンを見つける

認証障害が断続的、または環境依存に見える場合は、まずexpに注目してください。

{"sub":"user-123","exp":1712732400}

カスタムクレームを確認

トークンの形が問題なさそうでも、認可の不一致はaud、scope、subを見ると分かることが多いです。

{"aud":"api://comutil","scope":"read:users write:users","sub":"user-123"}

セグメント構造を確認

JWTは3つのBase64URLセグメントで構成されるため、句読点やパディングの崩れだけでもコピーしたトークンが壊れることがあります。

header.payload.signature

APIを疑う前に確認すること

時計ずれはexpとiat、オーディエンス不一致はaud、権限不足はscopeを確認してください。これらは通常、リクエストを再現するより早く原因を絞れます。

デコードは署名を検証しません

このページはトークン構造とクレーム内容を読み取ります。署名の検証、信頼チェーンの検証、期待した署名者が発行したかの確認は行いません。