こんにちは、tampopo256 です。

今回は、自分が実際にやらかしてしまった「セッション管理の失敗」を赤裸々に綴ります。
これからWebアプリを作る人、すでにJWTを使っている人は、「あ、これ自分もやってるかも」と感じるかもしれません。

💥やらかしポイント

開発初期、セッション管理が面倒という理由で、JWTの有効期限を365日に設定していました。

const token = jwt.sign(payload, SECRET_KEY, {
  expiresIn: "365d"
})

その結果どうなったか？

これはもう、「セッション管理してるつもり」になっていただけの状態でした。

JWTの期限が切れてしまうと、ユーザーは突然ログアウト状態に。

「なんか急に落とされた」「バグでは？」と感じるユーザー続出。
開発側も「なぜログイン状態が維持されないのか？」と毎回悩む始末。

なぜか？

→ リフレッシュトークンを発行するAPIを作っていなかったからです。

🧯本来どうするべきだったのか

トークン種別	用途	有効期限	保存場所	失効時の対処
アクセストークン	API認証に使用	15〜60分	メモリ or Cookie	リフレッシュトークンで再取得
リフレッシュトークン	再発行の認証用	数日〜数週間	httpOnly Cookie推奨	再ログインを要求

1. ログイン時に
   - アクセストークン（短命）
   - リフレッシュトークン（長命）
   を発行

2. API通信はアクセストークンで認証

3. アクセストークンが切れたら
   → リフレッシュトークンで再取得

4. 両方切れたら
   → ログイン画面へリダイレクト

JWTは「状態を持たない」トークンですが、それは管理の責任が減るという意味ではない。

実際のシステムでは：

トークン保存場所としてlocalStorageを使っていたこともありましたが、XSSに対して無防備でした。

本来であれば以下の通りにするべきです。

セッション管理は、サービスの「入り口」であり「防波堤」です。
そこが雑だと、どんなにUIが良くても、どんなに便利な機能があっても信用を失います。

この記事を読んでくださった方には、ぜひ最初から「ちゃんとしたセッション管理設計」をしてほしいです。