セッション認証（Cookie）

どんな仕組みか

セッション認証は、ログイン後の状態をサーバ側に保持し、利用者にはセッション ID だけを Cookie で渡す、伝統的な Web 認証方式です。

サーバは「このセッション ID は誰のものか」を内部に記録しておき、リクエストごとに送られてくる ID と突き合わせて本人を識別します。状態をサーバが握っているのが特徴です。

どう動くのか

おおまかな流れは次のとおりです。

• ログイン成功時、サーバがセッションを作り、セッション ID を発行する
• セッション ID を Cookie に入れてブラウザへ返す
• 以降のリクエストでブラウザが Cookie を自動送信し、サーバが照合する

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax

セッションの実体（ユーザー情報や有効期限）はサーバ側にあり、ID はそれを指す引換券のような役割です。

他の方式との違い

ステートレスな JWT との対比で捉えると分かりやすいです。

• セッション：状態はサーバが持つ。サーバ側で削除すれば即座に失効できる
• JWT：状態はトークンが持つ。手元で検証できるが即時失効が難しい

ログアウトや強制的な無効化を確実に効かせたい場合、サーバ側で状態を管理できるセッション方式が扱いやすくなります。

使いどころ・注意点

一般的な Web アプリで、確実なログアウトやセッション管理を重視するなら有力です。Cookie には HttpOnly・Secure・SameSite を適切に設定し、盗まれにくくします。

サーバを複数台にスケールさせると、どのサーバでも同じセッションを参照できるよう、Redis などの共有ストアが必要になります。ここが単一障害点や性能のボトルネックにならないよう設計します。