セッション は、複数回の HTTP リクエストを 同じ利用者の連続した利用 として扱うための考え方です。
HTTP 自体は前回の通信内容を覚えないため、ログイン状態、権限、一時的な処理状態を保つには、別の仕組みでつなぐ必要があります。
多くの Web アプリでは、サーバー側でセッション情報を持ち、ブラウザにはその参照用のIDを Cookie で持たせます。
そのため、ブラウザが持っているのは詳細な認証情報全部ではなく、サーバー側のセッションを引くための値 であることが多いです。
セッションに入る情報の例は次のようなものです。
- ログイン済みかどうか
- どのユーザーか
- 権限やロール
- 一時的な認証状態
- CSRF 対策用の情報
ここでのポイントは、Cookie とセッションを分けて考えることです。
Cookie は値を運ぶ仕組みで、セッションは状態をひもづけて管理する考え方です。ログイン状態は、その2つを組み合わせて実現されることが多いです。
また、安全に使うには、ログアウト時の失効、権限変更時のセッション更新、タイムアウト設定、Cookie 属性の見直しまで含めて設計する必要があります。
セッションが残り続けたり、盗まれたCookieで再利用できたりすると、なりすましのリスクが高まります。
特に運用で差が出るのは、いつ新しいセッションIDに切り替えるか と いつ切るか です。
ログイン直後や権限変更直後にセッションIDを更新しないと、セッション固定化のような問題につながることがあります。また、長時間放置されたセッションを自動失効させるアイドルタイムアウトや、一定時間で再認証を求める設計も重要です。
セッションの保存先も実装次第です。
アプリケーションサーバーのメモリ、Redis、データベースなどに保存されることがあり、構成によって失効のしやすさやスケール方法も変わります。なので、セッションは単なる概念ではなく、認証と運用設計の両方に関わる部品です。
要するにセッションは、複数回の通信を同じ利用者の続きとして扱うための状態管理 です。
詳しくは Cookieとは？セッションやログイン状態とどう関係するのか で整理しています。