はじめに
JWT（JSON Web Token）は API 認証でよく使われますが、
「JWT の exp（有効期限）って変更できる？延長できる？」
と疑問に思う人は多いです。
この記事では、クライアント側・サーバ側の両方から、
- exp を変更できるのか？
- なぜ変更できないのか？
- 延長したいときはどうするのか？
を図解つきで説明します。
1. 結論：JWT の exp は 変更不可
- クライアント側 → 変更不可（署名が壊れる）
- サーバ側 → 変更不可（既存 JWT を改ざんできない）
唯一可能なのは：
✔ 新しい JWT を再発行すること（延長＝再発行）
2. JWT 改ざんがなぜバレるのか（図解）
以下の図は、「exp を書き換えると必ず失敗する」仕組みを示しています。
Mermaid 図：JWT の検証フロー
✔ 重要ポイント
- payload（exp など）を 1 文字変えても 署名は絶対に一致しない
- 署名に必要な鍵（secret/private key）はクライアントは持っていない
- → 改ざんした JWT は 100% バレる
- → exp を書き換える「延長」は不可能
3. サーバ側でも exp を編集できない理由
サーバには秘密鍵があるので「書き換えられそう」に感じますが、それは 既存トークンの編集ではなく“別の新しいトークン”を作ること。
つまり：
既存JWTは immutable（不変）。
作り直す＝新しいJWTとして再発行するだけ。
変更ではなく交換です。
4. JWT の有効期限を延長する正しい方法（図解つき）
JWT を延長する唯一の方法は、
✔ 新しい JWT を再発行すること
（多くの場合 Refresh Token を使う）
Mermaid 図：Access Token + Refresh Token フロー
✔ この仕組みで “延命” を実現しているだけ
exp を変えているのではない。
5. exp を改ざんできてしまう場合（脆弱実装）
以下のようなバグがある場合だけ、exp 改ざんが成功する：
- 署名検証が無効（verify_signature=False）
-
alg: "None"を許可 - HS256 の secret が弱くて Hashcat で破れる
- RS256 と HS256 のアルゴリズム混同
これらは 実装の脆弱性 であり、JWT の設計とは無関係。
まとめ
-
既存 JWT の exp を変更することはできない
- クライアント：署名破損で即死
- サーバ：改ざんできない（再発行しかできない）
-
延長したいなら
- Refresh Token を使って 新しい JWT を再発行する
- これが唯一の安全な方法
-
exp 改ざんが成功するケースは「脆弱JWT」のときのみ
正常実装では絶対に起こらない。