01
秒単位を確かめる
exp、nbf、iatのNumericDateはUnix秒です。ミリ秒の値をそのまま使わないでください。
開発者向けリファレンス
JWTクレームとOAuthエラー
クレーム名やOAuthエラーコードを検索し、応答の場所、架空例、RFCの出典を確認します。
JWTクレーム
一致した項目
exp
応答の場所: JWTクレーム · RFC 7519
意味: 有効期限です。NumericDateはUnix秒単位です。
ミリ秒ではなくUnix秒で比較します。
架空の応答例
{ "exp": 1893456000 }架空データです。実際の認証情報として使わないでください。
検索はブラウザー内のみ。出典リンクを選んだ場合だけ移動します。
種類
1件表示／全23件
RFC 7519 / 6749 / 6750確認日：2026年9月23日
JWTクレームのexpやaudを見ても、値の意味とトークン検証は別です。この資料では登録済みフィールドの用途と形式を、認証情報を貼らずに確認できます。
OAuthの同じエラー名でも認可リダイレクト、トークン応答、Bearerのヘッダーで位置が異なります。まず発生箇所を絞ってください。アクセストークンクレームは提供元ごとに追加されます。invalid_grantエラーはトークン応答の文脈で確認します。
JWTクレームを調べる理由
JWTクレームを調べる理由
値だけで判断しない
JWTクレームのexpはUnix秒の架空例とRFCへのリンクを並べます。ペイロードの表示だけでは署名や有効性を確認できません。
エラーの場所を分ける
invalid_requestはリダイレクトのクエリ、JSON本文、Bearerヘッダーのどこにも現れます。返却位置を見れば取り違えを減らせます。
正しい文脈で読む
02
発生場所を確かめる
OAuthエラーコードを見たら、認可、トークン、リソースのどこで返ったかを先に選びます。
03
規範の節へ進む
固定されたRFCの節と提供元の資料を確認し、実トークンの調査は専用デバッガーで行います。
フィールドから原典まで
登録済みの七項目
RFC 7519の七つのJWTクレームに、架空の値と個別の定義リンクを付けています。
エンドポイント別のエラー
RFC 6749の認可応答とトークン応答を分け、同名エラーでも文脈を残します。
Bearerの応答形式
RFC 6750に基づくWWW-Authenticateヘッダーと推奨HTTP状態を示します。
参照資料の対象範囲
- 認証結果は判定しない
- このJWTクレーム資料はトークンを受け取らず、署名やセッション状態を検証しません。
- 拡張は網羅しない
- RFC 7519、6749、6750の範囲です。OIDCや各社固有コードを自動追加しません。
- 説明文で分岐しない
- error_descriptionは任意の人向け情報です。処理はerror値とエンドポイントを基準にします。
- 認証情報を入力しない
- 実際のJWT、署名鍵、認可コードを貼り付けたりURLパラメータに入れたりしないでください。固定資料だけを検索します。
- サーバーを照会しない
- 検索でIDプロバイダーに通信せず、関連ツールへ値を自動送信しません。実際の要求は専用ツールで確認します。
- エラーの場所を残す
- 同じinvalid_requestでも応答場所は異なります。Bearerのinvalid_tokenとinsufficient_scopeも推奨状態が違います。
- 現在の期限は判定しない
- NumericDateの例はUnix秒です。固定値から実際のセッションや未入力のトークンの期限は判断できません。
JWTクレームのよくある疑問
JWTのissとaudは何を示しますか？
issは発行者、audは想定受信者です。実際の受信側で両方を検証する必要があります。
expクレームはすべてのJWTで必須ですか？
一律には必須ではありません。RFC 7519は登録していますが、必須条件は利用するプロファイル次第です。
invalid_grantとinvalid_clientはどう違いますか？
invalid_clientはクライアント認証、invalid_grantは認可グラントや更新トークンの問題です。
error_descriptionを判定条件に使えますか？
使うべきではありません。任意の人向け説明で、提供元によって文言が変わります。
JWTをデコードすれば有効性も確認できますか？
できません。デコード後も署名、発行者、受信者、時刻、運用ポリシーの検証が必要です。
項目の不足や誤りを見つけましたか？