Cookie・セッション・JWT（Web認証）

なぜ状態保持が要るのか

HTTP は1回のリクエスト／レスポンスで完結し、前回を覚えていません。ログインフォームに ID とパスワードを送って認証が通っても、次の GET /mypage は別の通信なので、サーバは何も知らない状態からやり直します。

毎回パスワードを送らせるのは論外（盗聴・漏洩リスク）。そこで「最初に1回だけ本人確認 → 以降は短い合言葉で済ます」という流れにします。この合言葉をブラウザとサーバの間で持ち回る仕組みが、これから見る Cookie とセッション／JWT です。

Cookie：印を運ぶ箱

Cookie は、サーバがブラウザに「これ持っといて」と渡す小さなテキストです。仕組みはシンプルで、ヘッダのやり取りだけで成立します。

# サーバ → ブラウザ（ログイン成功時のレスポンス）
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Max-Age=3600

# 以降、ブラウザ → サーバ（同じサイトへのリクエストに自動で付く）
GET /mypage HTTP/1.1
Cookie: session_id=abc123

ポイントは、一度受け取った Cookie をブラウザが同じサイト宛のリクエストに自動で付け続けること。開発者が JS で何もしなくても付与されます（後述の CSRF はこの「自動で付く」性質が原因）。よく使う属性を押さえておきましょう。

セッション vs JWT：正体をどこに置くか

ログイン後の「あなたは誰か」という情報をどこに保管するかで、2つの方式に分かれます。

• サーバセッション：正体（ユーザーID・権限など）はサーバ側に保存。ブラウザには中身のないランダムなID（セッションID）だけを渡す。IDはサーバ内のデータを引く「ロッカーの鍵」。
• JWT（JSON Web Token）：正体そのものを署名付きで本人に持たせる。サーバは保管せず、届いたトークンの署名を検証するだけで本人と分かる。

// JWT は 3 つの部分を「.」で連結（ヘッダ.ペイロード.署名）
// xxxxx.yyyyy.zzzzz
// ・ヘッダ   : 署名アルゴリズム（例 HS256）
// ・ペイロード: { "sub": "u123", "role": "admin", "exp": 1717400000 }
// ・署名     : 上記2つをサーバの秘密鍵で署名 → 改ざんすると検証に落ちる

両者の性質は、ほぼ正反対です。

つまずきポイント：保存場所と XSS / CSRF

「JWT をどこに保存するか」で迷うのは定番です。HttpOnly Cookie か、localStorage か。これはどの攻撃に弱くなるかのトレードオフで、安易に決めると穴になります。

• XSS（クロスサイトスクリプティング）：攻撃者の JS をページ内で実行される攻撃。localStorage のトークンは JS から読めるので丸ごと盗まれる。一方 HttpOnly Cookie は JS から読めないので、トークン本体は抜かれにくい。
• CSRF（クロスサイトリクエストフォージェリ）：利用者がログイン中の別サイト（罠ページ）から、本物サイトへ勝手にリクエストを飛ばす攻撃。Cookie は自動で付くため成立しうる。localStorage は手動で付ける（自動で付かない）ため、この攻撃には強い。

認証の流れ（最小例）

サーバセッション方式の往復を、ログインから保護ページ表示まで擬似コードで追います。

// 1) ログイン：本人確認できたらセッションを作り、ID を Cookie で渡す
app.post('/login', async (req, res) => {
  const user = await verifyPassword(req.body.id, req.body.password);
  if (!user) return res.status(401).send('Unauthorized'); // 401 = 誰か不明
  const sid = createSession(user.id); // サーバ側ストアに { sid → user.id } を保存
  res.cookie('session_id', sid, { httpOnly: true, secure: true, sameSite: 'lax' });
  res.send('ok');
});

// 2) 保護ページ：届いた Cookie の ID でサーバ側を引き直す
app.get('/mypage', (req, res) => {
  const userId = lookupSession(req.cookies.session_id); // ストアから逆引き
  if (!userId) return res.status(401).send('Login required');
  res.send(`Hello user ${userId}`);
});

401（未認証＝誰か不明）と 403（認証済みだが権限なし）の違いは、HTTP のステータスコードで押さえたとおり。ログインを促すのが 401、ログイン済みでも立入禁止なのが 403 です。

関連トピックとして、別オリジンの API を JS から叩くときに立ちはだかる CORS、そして認証情報を狙う攻撃面そのものは JavaScript や DOM の理解とも地続きです。