はじめに
― 有効期限（exp）を正しく管理しないとどうなるか ―
JWT は「署名が正しければ有効」と思われがちですが、もう一つ重要なチェック要素があります。それが 有効期限（exp） です。
JWT は一度クライアントへ渡ったら、基本的にサーバ側で削除できません。
そのためレイテンシの長い API や分散システムにおいては、「トークンがいつまで生きるか」の設計が非常に重要です。
1. Token Lifetime（トークンの寿命）
JWT はサーバ側で強制的に削除できません。
Cookie ならサーバ側で「失効」処理が可能ですが、JWT にはその機能がないため、
-
expが長すぎる - そもそも
expが設定されていない
という状態だと、攻撃者がトークンを手に入れたら永遠に使えてしまう という最悪の事態になります。
✔ exp がないJWTはどうなる？
ほとんどの JWT ライブラリはこう動きます：
exp が無ければ、署名さえ正しければ常に有効と判定する
つまり「半永久トークン」が誕生してしまいます。
2. どれくらいの exp が適切？
アプリの性質によって変わります：
| サービス例 | 安全要求 | 推奨寿命 |
|---|---|---|
| Webメール | 中 | 数時間〜数日 |
| SNS | 中～高 | 数十分〜数時間 |
| 銀行/金融 | 高 | 数分 |
| 管理コンソール | 非常に高 | 数分 |
長くしすぎると漏えい時の impact が増え、短くしすぎるとユーザ体験が落ちます。
現実的には 短めのAccess Token + Refresh Token が一般的なベストプラクティスです。
3. “Token Revocation Problem”
有効期限前に無効化したい場合どうする？
JWT は stateless なので、サーバ側から「このトークンを今すぐ無効化して」ということができません。
そのため実務では「Blocklist（無効化リスト）」を保持する必要があります。
ただし：
- 分散APIだと複数サーバで同期する必要がある
- キャッシュ層や microservice 全体で管理が必要
- 結果として “centralized session” に逆戻り
JWT を乱用すると本来のメリットを失うため、設計は慎重に行う必要があります。
4. Practical Example 6（TryHackMe）
この例の JWT は exp が設定されていないため永続トークン。
提供された token をそのまま使うだけで admin としてログインできます：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InVzZXIiLCJhZG1pbiI6MX0.ko7EQiATQQzrQPwRO8ZTY37pQWGLPZWEvdWH0tVDNPU
実行ログ：
curl -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InVzZXIiLCJhZG1pbiI6MX0.ko7EQiATQQzrQPwRO8ZTY37pQWGLPZWEvdWH0tVDNPU' \
http://MACHINE/api/v1.0/example6?username=admin
結果：
{
"message": "Welcome admin, you are an admin, here is your flag: THM{a450ae48-7226-4633-a63d-38a625368669}"
}
5. The Development Mistake
開発者が JWT に exp を入れ忘れるか、意図的に無期限にしてしまったこと。
ほとんどのライブラリは exp がなければ有効と判断してしまうため、攻撃者が盗んだら「永遠に使える」危険なトークンとなる。
6. The Fix（修正方法）
JWT 発行時に必ず exp を設定します：
lifetime = datetime.datetime.now() + datetime.timedelta(minutes=5)
payload = {
'username' : username,
'admin' : 0,
'exp' : lifetime
}
access_token = jwt.encode(payload, self.secret, algorithm="HS256")
これによりライブラリ側が期限チェックを自動的に行い、期限切れトークンを拒否するようになります。
まとめ
JWT の有効期限に関する重要ポイントは以下のとおり：
- exp がなければ JWT は“永遠に使える”危険なトークンになる
- JWT はサーバ側で削除できないため、exp の設計を間違えると重大事故につながる
- 漏えい対策として、短いAccess Token + Refresh Token が推奨
- JWT の詐取＝アカウント乗っ取り。
exp がなければ「永続セッション」として悪用される。 - セキュリティ設計の原則：
“短めの exp を必ず設定すること”