セッション管理
セッション管理とは
[[HTTP]] はステートレス(各リクエストが独立していて、前のやり取りを覚えていない)なプロトコルです。そのままでは「さっきログインした人」をサーバーが識別できません。この「状態を覚える」問題を解決するのがセッション管理です。
基本のアイデアはシンプルです — サーバーが利用者ごとにセッションIDという札を発行し、以降のリクエストでその札を見せてもらうことで本人を識別します。
Cookieを使った典型的な流れ
- ユーザーがIDとパスワードでログインする
- サーバーがセッションIDを発行し、対応するユーザー情報をサーバー側(メモリやRedisなど)に保存する
- セッションIDを Cookie としてブラウザに渡す
- ブラウザは以降のリクエストに Cookie を自動で添付する
- サーバーはセッションIDからユーザーを特定する
Cookie の細かい仕組みは [[WebストレージとCookie]] で解説されています。ここで重要なのは、セッションIDそのものには意味がなく、実体はサーバー側にあるという点です。
トークン方式との比較
サーバーに状態を持たない [[JWT]] を使う方式もあり、両者はよく比較されます。
| セッション方式 | JWT方式 | |
|---|---|---|
| 状態の置き場所 | サーバー側 | トークン自体(クライアント側) |
| 即時無効化 | 容易(サーバー側で消すだけ) | 難しい(有効期限まで生きる) |
| サーバーの負担 | セッションストアが必要 | 署名検証のみ |
| 向く場面 | 通常のWebアプリ | API・分散システム |
「ログアウトさせたら即座に無効にしたい」通常の Web アプリでは、今もセッション方式が堅実な選択です。
セキュリティの必須設定
セッションIDが盗まれるとなりすましが成立するため、Cookie には守りの属性を必ず付けます。
HttpOnly— JavaScript から Cookie を読めなくする(XSS 対策)Secure— HTTPS のときだけ送信するSameSite— 他サイト起点のリクエストへの自動添付を制限する(CSRF 対策)- ログイン成功時にセッションIDを再発行する(セッション固定攻撃対策)
これらの攻撃の詳細は [[Webセキュリティ]] を参照してください。
関連技術とのつながり
- [[認証と認可]] — セッション管理は「認証した状態を維持する」ための土台
- [[HTTP]] — ステートレスであることがセッション管理の存在理由
- [[WebストレージとCookie]] — セッションIDの運搬役である Cookie の仕組み
- [[JWT]] — サーバーに状態を持たない対抗馬。使い分けが重要
- [[スケーリング]] — 複数台構成ではセッションを Redis などの外部ストアへ置く必要がある
Q: セッション管理が必要になる理由はどれ?
- [x] HTTPがステートレスで、前のやり取りを覚えていないから
- [ ] HTTPの通信速度が遅いから
- [ ] ブラウザがJavaScriptを実行できないから
解説: HTTP は各リクエストが独立しているため、セッションIDでログイン状態を識別する仕組みが必要です。
Q: セッション方式でユーザー情報の実体が保存される場所はどれ?
- [ ] Cookieの中
- [x] サーバー側(メモリやRedisなど)
- [ ] DNSサーバー
解説: Cookie に入るのはセッションIDという札だけで、実体はサーバー側のセッションストアにあります。
Q: JavaScriptからCookieを読めなくする属性はどれ?
- [ ] SameSite
- [ ] Secure
- [x] HttpOnly
解説: HttpOnly を付けると JavaScript から Cookie にアクセスできなくなり、XSS でのセッションID窃取を防ぎます。