ログイン状態が保持される流れ - Cookieセッションの深掘り

中級 | 13分 で読める | 2026.06.27

公式ドキュメント
AuthHTTP

この記事の位置づけ

この記事では、Cookieセッションでログイン状態が保持される流れを深掘りします。

重要なのは、ブラウザが持つのはセッションIDであり、ログイン状態の本体はサーバー側のセッションストアにある、という分離です。

「セッションIDとは何か」は別記事で扱っているため、ここでは実務で設計・調査するときに見るべき細部に寄せます。

全体の流れ

Cookieセッションの流れは、次のように分けられます。

1. ログインフォームを送る
2. サーバーが認証する
3. サーバーが新しいセッションIDを発行する
4. セッションストアに userId や権限を保存する
5. Set-Cookie でブラウザへ session_id を渡す
6. 次回以降、ブラウザが Cookie を自動送信する
7. サーバーが session_id を使ってストアを引く
8. 有効ならログイン済みとして処理する

HTTPで見ると、ログイン成功時は次のようになります。

HTTP/1.1 302 Found
Set-Cookie: session_id=s%3A9Jp...; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=7200
Location: /dashboard
Cache-Control: no-store

その後、マイページを開くとブラウザがCookieを送ります。

GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_id=s%3A9Jp...

JavaScriptが session_id を読んで送っているわけではありません。Cookieの条件に合えば、ブラウザがHTTPヘッダーへ自動で付けます。

セッションIDは「ユーザー情報」ではない

セッションID自体に、メールアドレス、氏名、権限、プラン情報を入れるべきではありません。

良い考え方:

session_id = ランダムな参照キー

サーバー側のストア:

{
  "session:s%3A9Jp...": {
    "userId": "user_001",
    "role": "student",
    "loginAt": "2026-06-27T10:00:00.000Z",
    "lastSeenAt": "2026-06-27T10:20:00.000Z",
    "authLevel": "password"
  }
}

セッションIDに求められる性質は、推測困難であることです。連番、短い文字列、ユーザーIDを含む値、日時から推測できる値は避けます。十分に長いランダム値を使い、フレームワークや認証ライブラリの安全な生成機能に任せるのが基本です。

ログイン時にはセッションIDを再発行する

深いポイントはここです。

ログイン前から存在していた匿名セッションIDを、ログイン後もそのまま使い続けるのは危険です。

ログイン前:

anonymous session_id = old_abc

ログイン成功後:

authenticated session_id = new_xyz

このように、認証状態が変わるタイミングでセッションIDを再発行します。これにより、攻撃者が事前に知っているセッションIDを、ログイン後の本人セッションとして使わせる「セッション固定攻撃」を防ぎやすくなります。

再発行時に見ること:

  • 古いセッションIDを無効化する
  • 新しいセッションIDを発行する
  • 必要な匿名セッション情報だけを移す
  • CSRFトークンも必要に応じて再発行する
  • 権限昇格時にも再発行を検討する

管理者画面へ入る、2要素認証を通過する、決済操作へ進む、のように認証レベルが上がる場面でもセッション更新を検討します。

セッションストアの役割

本番環境では、セッションをアプリサーバーのメモリだけに置くと問題になりやすいです。

保存先向いている場面注意点
メモリローカル開発、小規模検証再起動で消える、複数台に弱い
Redis一般的なWebアプリTTL管理、永続化設定、障害時の扱い
RDB監査や管理を重視高頻度アクセスでは負荷に注意
KV / DynamoDBサーバーレスTTL反映の遅延、読み書き設計

複数台のアプリサーバーで動く場合、どのサーバーに当たっても同じセッションを読める必要があります。

Browser
  -> App Server A
  -> App Server B
  -> Redis Session Store

メモリセッションのまま複数台にすると、Aではログイン済み、Bでは未ログインという状態が起きます。ロードバランサーのsticky sessionで回避する方法もありますが、障害・スケール・デプロイ時に弱くなるため、共有ストアを使う方が素直です。

期限は2種類で考える

セッション期限は、1つだけではありません。

種類意味
Idle timeout最後の操作から一定時間で切る
Absolute timeout操作していても最大時間で切る

たとえば、次のように分けます。

Idle timeout: 30分操作がなければ失効
Absolute timeout: ログインから24時間で必ず失効

Idle timeoutだけだと、操作し続ける限りセッションが長く残ります。Absolute timeoutだけだと、短時間の放置を検知しにくくなります。重要な画面では、両方を組み合わせます。

実装では、Cookieの Max-Age とセッションストアのTTLを揃える必要があります。Cookieだけ残っていてもストアが消えていれば未ログインになり、ストアだけ残っていてもCookieがなければ参照できません。

Sliding expirationの落とし穴

アクセスするたびに期限を延長する方式を、sliding expiration と呼ぶことがあります。

リクエストごとに Redis TTL を30分へ延長

便利ですが、すべてのリクエストでTTL更新すると負荷が増えます。画像、CSS、ヘルスチェック、プリフェッチで期限が伸びると意図しない挙動になります。

実務では、次のように制御します。

  • 認証が必要なHTML/APIだけで更新する
  • 一定時間以上経過したときだけ更新する
  • Absolute timeoutを別に持つ
  • バックグラウンド通信だけで延命しないようにする

「ユーザーが操作している」と「ブラウザが自動通信している」は分けて考えます。

Cookie属性の基本セット

ログインセッションCookieでは、少なくとも次を検討します。

Set-Cookie: session_id=...; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=7200
属性目的
HttpOnlyXSS時にJavaScriptから直接読まれにくくする
SecureHTTPS通信に限定する
SameSite=Lax一般的なCSRFリスクを下げる
Path=/アプリ全体で送る
Max-Ageブラウザ側の期限を決める

サブドメイン間でCookieを共有したい場合だけ Domain を検討します。不要に Domain=example.com を付けると、サブドメイン全体へ送信範囲が広がります。認証Cookieは、できるだけ狭い範囲へ送る方が扱いやすいです。

キャッシュとの関係

ログイン後の個人ページでは、HTTPキャッシュにも注意します。

Cache-Control: no-store

ログイン済みページや個人情報を含むAPIレスポンスを、共有キャッシュやブラウザ履歴から見られる状態にしないためです。

特に次のページは慎重にします。

  • マイページ
  • 管理画面
  • 決済履歴
  • 個人情報編集
  • 学習進捗や相談内容

「セッションが切れているのに戻るボタンで画面が見える」という現象は、サーバー認証ではなくブラウザキャッシュの問題で起きることがあります。

CORSとcredentials

フロントエンドとAPIが別オリジンの場合、Cookie送信には追加条件があります。

ブラウザ側:

fetch("https://api.example.com/me", {
  credentials: "include"
});

サーバー側:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true

Access-Control-Allow-Origin: * と認証Cookieの組み合わせは使えません。Cookieを送る場合は、許可するオリジンを具体的に返します。

ただし、これはCORSの話であり、SameSiteとは別です。CORSはJavaScriptからレスポンスを読めるか、SameSiteはCookieが送られるか、という別の制御です。

ログに残すべきもの、残してはいけないもの

調査のためにセッション情報をログに出したくなることがあります。しかし、セッションIDそのものを平文でログに残すのは危険です。

避けるもの:

  • Cookie ヘッダー全文
  • セッションID全文
  • Authorizationヘッダー
  • CSRFトークン
  • 個人情報を含むセッション内容

残すなら、次のように最小限にします。

session_present=true
session_id_hash=sha256先頭8文字
user_id=user_001
session_age_seconds=1200
auth_level=password

調査できる情報と、漏れたときに危険な情報を分けます。

まとめ

Cookieセッションは、Cookie、セッションストア、期限、キャッシュ、CORSが連動して成り立ちます。

  • ブラウザはセッションIDだけを持つ
  • ログイン状態の本体はサーバー側に置く
  • ログイン時や権限昇格時はセッションIDを再発行する
  • Cookie期限とストアTTLを揃える
  • Idle timeoutとAbsolute timeoutを分けて考える
  • 個人ページには Cache-Control: no-store を検討する
  • セッションIDをログにそのまま残さない

単に「Cookieがあるからログイン済み」ではなく、「CookieのIDでサーバー側の有効なセッションを引けるからログイン済み」と理解すると、設計と調査が安定します。

参考リソース

次に読む記事

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR