落とし穴

JWT の有効期限を計算するコードと、環境変数で渡す値の単位がずれていると、有効期限が桁違いになる。例として、設定値を「秒」のつもりで渡しているのにコードが time.Hour * value のように「時間」として扱うと、意図の数千倍の有効期限になる。レビューでは「生成コードの単位」と「設定値の単位」が一致しているかを必ず突き合わせる。

設計判断

ステートレスな JWT はサーバー側に失効機構がなく、ログアウトはクライアントのトークン破棄に過ぎないことが多い。そのため一度漏れたトークンは有効期限まで使い続けられる。漏洩時の被害窓を小さくするには有効期限を短くしたいが、リフレッシュ機構がないと非アクティブ時に即ログアウトになり UX が悪化する。

ここで、認証ミドルウェアがリクエストごとにトークンを再発行・再設定する設計なら、アクティブな利用中は失効せず、有効期限は実質「非アクティブタイムアウト」として働く。この場合は有効期限を短く（数十分〜1日程度）しても UX を保ちつつ漏洩リスクを下げられる。逆に再発行しない設計では、短命化とリフレッシュトークン導入をセットで検討する。

検証観点

トークンの exp を実際にデコードして想定どおりの期限か確認する。Cookie に載せる場合は Max-Age の単位（秒）も同時に確認する。アクティブ利用で期限が自動更新されるか、無操作で想定時間後に失効するかを実機で確認する。