JWT セッション 設計は失効要件から考える
設計で迷う場面は、実務ではかなり多いです。JWTを使えばステートレスにできるのか。セッション管理は古いのか。refresh tokenをどこに保存するのか。ログアウト時に本当に無効化できるのか。こうした判断は、単なる方式比較では決まりません。
結論から言うと、JWTかセッションかは、失効要件、有効期限、保存場所、クライアント種別、監査要件で決めます。特に「即時に止めたい権限変更や退職者対応があるか」は、設計の大きな分岐点です。
この記事では、Spring Boot/API開発を想定し、JWTとセッション設計でレビューしたい判断軸を整理します。
JWTとセッションの違いを運用で見る
JWTは、署名されたトークンにclaimsを入れて検証できます。Spring Security公式のOAuth2 Resource Server JWTでも、JWTの検証やリソースサーバーの考え方が整理されています。
一方で、セッションはサーバー側に状態を持ちます。状態を持つ分、ログアウトや強制失効を扱いやすいです。ただし、スケールアウト、セッションストア、Cookie設定などの運用が必要になります。
| 観点 | JWT | セッション |
|---|---|---|
| 検証 | 署名とclaimsを検証 | セッションIDでサーバー側状態を参照 |
| 失効 | 期限切れまで残りやすい | サーバー側で無効化しやすい |
| スケール | 状態を持たずに検証しやすい | 共有ストアやsticky sessionが必要 |
| 情報更新 | claimsが古くなる場合がある | サーバー側状態を更新しやすい |
| 運用負荷 | 鍵管理と失効設計が重要 | ストア管理とCookie設計が重要 |
有効期限とrefresh tokenは短期と長期を分ける
access tokenを長くしすぎると、漏えい時の影響が大きくなります。一方で、短すぎると利用者体験やAPI呼び出しの安定性に影響します。そのため、access tokenは短めにし、refresh tokenで再発行する設計がよく使われます。
ただし、refresh tokenは長く使える分、より強く守る必要があります。端末単位で発行するか、再利用検知をするか、ローテーションするか、ログアウト時に無効化するかを決めます。
token lifetimeのレビュー観点
- access tokenの有効期限が業務リスクに合っている
- refresh tokenの保存場所と失効手段が決まっている
- 権限変更後に古いclaimsが残る時間を許容できる
- ログアウト、端末紛失、退職時の無効化手順がある
- 署名鍵ローテーション時の移行手順がある
CookieとlocalStorageは攻撃面で比較する
保存場所の議論では、CookieとlocalStorageがよく比較されます。localStorageはJavaScriptから扱いやすい一方で、XSSが起きたときにトークンを読み取られやすくなります。CookieはHttpOnlyを使えばJavaScriptから読み取りにくくできますが、CSRF対策やSameSite設定が必要です。
MDNのSet-Cookieでは、HttpOnly、Secure、SameSiteなどの属性が説明されています。実務では、保存場所だけでなく、XSS、CSRF、通信経路、サブドメイン、ログ出力まで含めてレビューします。
OWASPのJSON Web Token for Java Cheat Sheetも、JWT利用時の保管や失効の注意点を確認する材料になります。
JWT セッション 設計で起きやすい失敗例
| 失敗例 | 原因 | 予防策 |
|---|---|---|
| ログアウト後もJWTが使える | 失効リストや短い期限がない | 短命化、revocation、refresh token無効化 |
| 権限変更が反映されない | rolesをJWTに長期間保持 | 短い期限、再検証、重要操作時の権限確認 |
| XSSでtokenが盗まれる | localStorageに長期tokenを保存 | HttpOnly Cookie、CSP、XSS対策 |
| 署名鍵更新で全員ログアウト | 鍵IDと移行期間がない | kid、複数鍵検証、段階的ローテーション |
まとめ: JWTとセッションは要件から選ぶ
JWT セッション 設計では、方式名だけで優劣を決めないことが重要です。失効要件、有効期限、保存場所、クライアント種別、監査要件を見て、運用できる設計を選びます。
Spring Boot/API案件では、認証認可の設計判断がサービスの安全性と保守性に直結します。案件選びでも、こうした設計レビューに関われるかは経験者エンジニアにとって重要な観点です。
bluenaでは、Spring BootやREST APIの経験を活かしながら、認証認可設計やレビューに関わる案件について相談できます。
一度カジュアル面談をしませんか？
株式会社bluenaは「高還元」と「伴走支援」を両立したSES企業です。単価の81〜86%を還元する報酬体系と、専任サポーターによる隔週1on1で、エンジニアが納得できるキャリアを実現します。
まとまっていなくてもOK——まずは現在地を聞かせてください。
カジュアル面談ですので、お気軽にお聞かせください。
