token expired、jwt expired、時間が原因らしい 401 を見たとき、私はまず exp を確認します。ただし library の error text だけで決めず、token を decode し、timestamp を自分で変換し、実際に reject した verifier の clock と比較します。
手早く確認するなら JWT 有効期限チェック で exp、iat、nbf を UTC に変換します。
exp が意味するもの
RFC 7519 で exp は Expiration Time です。NumericDate で、Unix epoch からの 秒 を表します。
{
"sub": "user_123",
"iat": 1789200000,
"exp": 1789203600
}
conceptually verifier は：
current verifier time >= exp
になった後 token を reject します。
最初に確認するミス: 秒とミリ秒
JavaScript の Date.now() は milliseconds です。JWT NumericDate は seconds です。
正しくは：
const expiresAt = payload.exp * 1000;
const expired = Date.now() >= expiresAt;
私は：
Date.now() >= payload.exp
という比較を見たら units bug を疑います。
本当に expired か確認する順番
expが存在するか。- UTC timestamp に変換する。
- reject した service の clock と比較する。
nbfとiatも同時に見る。- verifier の clock tolerance を確認する。
自分の laptop time だけを authority にしないことが重要です。
clock skew をどう扱うか
RFC 7519 は小さな clock difference を吸収する leeway を実装が使えるとしています。
boundary 直前/直後なら私は：
- API server clock は synchronized か。
- issuer clock は synchronized か。
- JWT library に tolerance setting があるか。
を確認します。
error を消すために大きな grace period を入れません。それは issuer が宣言した acceptance window を実質的に伸ばします。
数秒の差なら skew の可能性がありますが、1 時間前に expired した token を skew で説明しません。
exp がないとき
base JWT specification に exp は registered claim としてありますが、すべての JWT profile が必須とするわけではありません。
そのため missing exp を universal malformed JWT と断定しません。
ただし short-lived bearer access token の profile で expiration が期待されるなら investigation 対象です。JWT Validator ではこの condition を確認しつつ、すべての profile に同じ rule を押し付けません。
unexpired でも failure する理由
exp が未来なら私は expiration から離れます。
- signature failure
nbfが未来- wrong issuer
- wrong audience
- 異なる実行環境
- wrong token type
- missing scope / role
など、別 layer の可能性があります。
issuer/audience は JWT デバッガー、trusted key があるなら JWT 署名検証 に進みます。
exp を編集して更新しない
signed token の：
{ "exp": 1789203600 }
を未来値に書き換えると signed bytes が変わります。authorized signing credential なしでは valid signature を作り直せません。
正しい renewal は refresh / reauthentication など system が提供する token acquisition flow です。
iat / nbf / exp を 1 timeline で見る
issued -------- active window -------- expired
iat nbf exp
私は：
iatは login timing と合うか。nbfが current time より後ではないか。expはiatより後か。- lifetime が異常に長い/短いか。
を確認します。
odd timeline は unit conversion、clock、異なる実行環境、profile policy の clue になります。
私の exp troubleshooting flow
- JWT 有効期限チェック を開く。
expを seconds として解釈する。- UTC を reject した verifier の clock と比較する。
iat/nbfに矛盾がないか見る。- configured tolerance を確認する。
- 本当に expired なら正規の flow で new token を得る。
- まだ active なら issuer、audience、signature へ進む。
exp が答えるのは declared time window の外かどうかです。token を trust / accept すべきかの全部ではありません。
