【保存版】🔐 HTTPとCookie・セッション・トークンの完全解説  

# ✅ はじめに

Webアプリケーションにおいて「ログイン状態を維持する」「ユーザーを識別する」といった機能は、すべて**セッション管理**に支えられています。

本記事では、

1. HTTP通信とステートレス  
2. Cookieの基礎から詳細仕様  
3. セッション管理の広義の定義  
4. セッションベース vs トークンベースのセッション管理  

これらをまとめて丁寧に解説します。

---

## ✅ 1. HTTP通信はステートレス

### ● ステートレスとは？

HTTPは「**ステートレス（stateless）**」なプロトコルです。  
つまり、**1回のリクエストとレスポンスが完結しており、前後の状態を保持しない**という特徴があります。

- 「このリクエストは誰から来たのか？」をサーバーは覚えていません。
- 毎回のリクエストが“初対面”のような扱いになります。

#### 🙋 たとえば…
ログイン後に別ページを開いたとしても、サーバーは「この人がログイン済み」という情報を持っていないため、  
**ログイン状態を維持できません**。

---

### ● ではステートフルとは？

一方で、「ステートフル（stateful）」な通信とは、**リクエストとレスポンスの間で状態を保持する仕組み**です。

つまり、「このリクエストは前にも来たあの人からだな」とサーバーが前回のやり取りを覚えている状態です。

サーバーは過去の接続情報やユーザーの状態を保持し、それをもとに次の処理を行います。

たとえばログイン後のユーザーに対して、「こんにちは、◯◯さん」と名前を出すような振る舞いは、サーバーが状態（セッション情報など）を記憶していることで可能になります。

---

### ●  なぜHTTPはステートレスに設計されたのか？

HTTPは元々「文書を取得する」ための仕組みとして設計されました。  
たとえば静的なHTMLや画像などをやり取りするだけなら、リクエストごとに完結している方がシンプルで効率的です。

ステートフルにすると、サーバー側で接続状態やユーザー情報を常に保持する必要があり、負荷が高まる・拡張性が低下するなどのデメリットもあるため、意図的に「ステートレス」に設計されているのです。

---

### ●  ステートレスの限界とセッション管理の必要性

一方で、ユーザーごとの状態を保持したいケース（ログイン状態の維持、買い物かごの中身など）は多く存在します。

これを実現するために登場するのが「**Cookie**」や「**セッション**」、「**トークン**」などの仕組みです。

HTTP自体はステートレスですが、アプリケーションレベルで状態を補完する手段を使って、ユーザーとの継続的なやり取りを実現しているわけです。

---

## 🍪 2. Cookieとは何か？

**Cookie**は、**Webブラウザに保存される小さなテキスト情報**です。  
主にサーバーとクライアント間でユーザーを識別するために使われます。

| 項目 | 内容 |
|------|------|
| 保存場所 | ブラウザ内の Cookieストア |
| 1件あたりのサイズ制限 | 約4KBまで（4096バイト前後） |
| ドメインごとの上限 | おおよそ20〜50個（ブラウザ依存） |
| 全体の上限 | 約300個まで（Chromeなど） |
| 自動送信 | 同一ドメインへのリクエストに自動添付される |

![Cookieのイメージ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/935631/7d9f42de-725e-4672-9f6c-7b96c8a82a07.png)

---

## 🔁 3. セッション管理とは？


**セッション管理とは「ユーザーの一連の操作を同一人物として扱う仕組み**です。  
つまり、「今アクセスしている人が誰か」をサーバーが識別・維持することです。

---

## 🧠 4. セッション管理の2つの方式

セッション管理には、主に以下の2つの方式があります。

### 🅰️ セッションベース（サーバーが覚える方式）

#### ■ 例え話：

記憶喪失の店員に「これ、私の会員カードです（セッションID）」と見せると、  
店員はカード番号から顧客情報（名前・購入履歴など）を**裏で確認**してサービスを提供してくれる。

#### ■ 特徴：

- クライアントには **セッションIDだけ** を渡す（中身は持たない）
- サーバーがそのIDに紐づいたユーザー情報を保持
- サーバーが状態を持つ → **ステートフル**

#### ■ メリット：

- 高いセキュリティ（情報はサーバー側にある）
- セッションを削除すれば即ログアウト可能

#### ■ デメリット：

- スケールしにくい（状態を持つので分散構成が複雑）
- 再起動などでセッションが失われるリスク（DB保存で対策可）

---

### 🅱️ トークンベース（クライアントが覚える方式）

#### ■ 例え話：

記憶喪失の店員に「この身分証明書（JWT）を見てください」と見せると、  
店員はその場で情報（名前、権限、有効期限など）を確認し、サービスを提供してくれる。

#### ■ 特徴：

- クライアントが**認証情報を含むトークン（JWT）**を保持
- サーバーは署名を検証して正当性を確認
- サーバーは状態を持たない → **ステートレス**

#### ■ メリット：

- サーバーにセッションストアが不要
- スケーラビリティに優れ、マイクロサービスやAPIと相性が良い

#### ■ デメリット：

- トークンが漏れると止めにくい
- トークンの中身はBase64で誰でも見られる（※暗号化ではない）

## 🔐 5. セキュリティ比較

| 比較項目 | セッションベース | トークンベース（JWT） |
|----------|------------------|------------------------|
| 状態の保持 | サーバー側 | クライアント側 |
| 情報の保存 | IDのみ（サーバーに実体） | ユーザー情報を含むトークン |
| XSS対策 | `HttpOnly` Cookieで対策可能 | `localStorage`はXSSに弱い。Cookie推奨 |
| CSRF対策 | `SameSite`, トークン併用 | Cookie保存時は同様に必要 |
| 漏洩時の対応 | セッション削除で即無効化可 | ブラックリスト、短期有効期限で対応 |

## ⚖️ 6. どちらを選ぶべき？

| シーン | 推奨方式 | 理由 |
|--------|-----------|------|
| 管理画面・社内ツール | セッションベース | セキュリティ重視、構成がシンプル |
| SPA（Reactなど）+ API構成 | トークンベース | ステートレスAPIと相性◎ |
| モバイルアプリ | トークンベース | サーバーレスに適応しやすい |
| 分散構成 / マイクロサービス | トークンベース | サーバー間でセッション共有不要 |

## 📝 まとめ

| 技術 | 状態管理者 | 保存場所 | 適性 |
|------|------------|-----------|------|
| Cookie | クライアント | ブラウザ | 状態を運ぶ入れ物 |
| セッションベース | サーバー | セッションIDをCookie | 安全・即時制御しやすい |
| トークンベース（JWT） | クライアント | Cookie or localStorage | スケーラブル、APIと相性良し |

---

## 📌 おわりに

HTTPは本質的に「**記憶喪失の店員**」のように、毎回“誰かわからない”設計です。  
だからこそ、**Cookieでメモを残し、セッションやトークンで文脈を再構築する**必要があります。

技術選定では、**安全性、拡張性、アプリの規模や性質**に応じて、  
「**どこに状態を持つか**」を適切に設計することが、セッション管理の本質です。

---