ステートレスJWTの有効期限は単位取り違えに注意し、再発行設計なら短命化する
JWT
セキュリティ
認証
落とし穴
JWT の有効期限を計算するコードと、環境変数で渡す値の単位がずれていると、有効期限が桁違いになる。例として、設定値を「秒」のつもりで渡しているのにコードが time.Hour * value のように「時間」として扱うと、意図の数千倍の有効期限になる。レビューでは「生成コードの単位」と「設定値の単位」が一致しているかを必ず突き合わせる。
設計判断
ステートレスな JWT はサーバー側に失効機構がなく、ログアウトはクライアントのトークン破棄に過ぎないことが多い。そのため一度漏れたトークンは有効期限まで使い続けられる。漏洩時の被害窓を小さくするには有効期限を短くしたいが、リフレッシュ機構がないと非アクティブ時に即ログアウトになり UX が悪化する。
ここで、認証ミドルウェアがリクエストごとにトークンを再発行・再設定する設計なら、アクティブな利用中は失効せず、有効期限は実質「非アクティブタイムアウト」として働く。この場合は有効期限を短く(数十分〜1日程度)しても UX を保ちつつ漏洩リスクを下げられる。逆に再発行しない設計では、短命化とリフレッシュトークン導入をセットで検討する。
検証観点
トークンの exp を実際にデコードして想定どおりの期限か確認する。Cookie に載せる場合は Max-Age の単位(秒)も同時に確認する。アクティブ利用で期限が自動更新されるか、無操作で想定時間後に失効するかを実機で確認する。