概要

HTTP自体は状態を持たないため、ログイン状態や利用者の識別には追加の仕組みが必要です。認証、Cookie、Session、Tokenの関係を整理すると、ログイン機能やAPI認証の設計が理解しやすくなります。

なぜ認証と状態管理が必要か

HTTPは基本的に各リクエストが独立しており、「前回ログインした人」と自然には結びつきません。そのため、利用者を識別する認証と、継続的な状態管理が必要になります。

たとえば、あるユーザーがログイン後に /mypage へアクセスしたとしても、HTTPだけを見ると単なる1回のリクエストです。サーバーは追加情報がなければ、次のことを判断できません。

誰からのリクエストか
すでにログイン済みか
どの権限を持つか
前回の操作と同じ利用者か

そのため、WebアプリやAPIでは次の仕組みが使われます。

認証: 誰かを確認する
認可: 何をしてよいかを決める
状態管理: ログイン中かどうかを継続して扱う

認証と認可の違い

認証は「あなたは誰か」を確認すること、認可は「あなたは何をしてよいか」を決めることです。この2つを混同しないことが重要です。

用語	意味	例
認証	利用者本人かを確認する	ログインIDとパスワードを確認する
認可	許可された操作かを判断する	管理者だけが削除APIを使える

ログインしていない → 認証されていない → 401 Unauthorized になりえます
ログインはしているが一般ユーザー → 認証は済んでいるが、管理機能では認可エラー → 403 Forbidden になりえます

401 と 403 の関係

ステータスコード	主な意味	例
`401`	認証が必要	トークン未送信、セッション切れ
`403`	権限がない	一般ユーザーが管理APIを呼ぶ

この区別は、API設計でもフロントエンドのエラー処理でも重要です。

HTTPがステートレスであるとは

HTTPはステートレスなプロトコルであり、各リクエストはそれ単体で完結します。前のリクエスト内容を自動では覚えていません。

たとえば、次の2回のリクエストがあっても、HTTPだけでは同じユーザーとはわかりません。

GET /login HTTP/1.1
Host: example.com

GET /mypage HTTP/1.1
Host: example.com

サーバーが「この人はさっきログインしたユーザーだ」と判断するには、追加の識別情報が必要です。その代表が、Cookie + Session と Tokenベース認証 の2系統です。

CookieとSessionの基本

Cookieはブラウザに保存される小さなデータで、Sessionはサーバー側で管理されるログイン状態です。両者はセットで使われることが多いです。

要素	主な保存場所	役割
Cookie	ブラウザ側	識別子などを保存して次回送信する
Session	サーバー側	ログイン状態やユーザー情報を保持する

典型的な流れは次の通りです。

ユーザーがログイン情報を送る
サーバーが認証に成功する
サーバーがSessionを作る
Session IDをCookieとしてブラウザへ返す
ブラウザは次回以降そのCookieを送る
サーバーはCookie内のSession IDからログイン状態を復元する

Cookieは何をしているか

Cookieはブラウザが自動で保存・送信する仕組みで、サーバーが毎回利用者を識別するための手がかりになります。

レスポンスでCookieを設定する例:

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; HttpOnly; Secure
Content-Type: text/html

次回リクエストでCookieが送られる例:

GET /mypage HTTP/1.1
Host: example.com
Cookie: session_id=abc123

session_id=abc123 自体にログイン情報本体が入っているとは限りません。多くの場合、サーバー側Sessionを引くための識別子として使われます。

Sessionは何をしているか

Sessionはサーバーが保持するログイン状態で、CookieはそのSessionを指すための鍵として使われます。

サーバー側では、たとえば次のような情報を持つことがあります。

Session ID	ユーザーID	権限	有効期限
`abc123`	`user_1`	`member`	`2026-05-05 12:00`

ブラウザは abc123 を送るだけで、実際の状態はサーバーが管理します。

Cookieベース認証の流れ

ブラウザ中心のWebアプリでは、Cookieベース認証が今でも非常に一般的です。ログイン画面を持つWebサービスでは特によく使われます。

ログイン時

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

email=test@example.com&password=secret

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax
Content-Type: text/html

この時点でブラウザは session_id を保存します。

ログイン後のアクセス

以後のリクエストでは、ブラウザが自動でCookieを送るため、サーバーはログイン済みユーザーとして扱えます。

GET /mypage HTTP/1.1
Host: example.com
Cookie: session_id=abc123

ログアウト時

ログアウトでは、サーバー側Sessionの無効化と、ブラウザ側Cookieの削除が行われます。具体的には、サーバーでSessionを破棄し、Set-Cookie で有効期限切れを返すことでブラウザがCookieを削除します。

Tokenベース認証の基本

APIでは、Cookieではなくトークンを Authorization ヘッダーで送る方式もよく使われます。SPAやモバイルアプリ、外部API連携で特に一般的です。

代表例はBearerトークンです。

GET /me HTTP/1.1
Host: api.example.com
Authorization: Bearer xxxxxx
Accept: application/json

この方式では、ブラウザやアプリはトークンを保持し、毎回ヘッダーに付けて送ります。

Token方式の特徴

よくある特徴:

モバイルアプリと相性がよい
外部API利用と相性がよい
Cookie自動送信に依存しない
フロントエンドがヘッダー制御しやすい

注意点:

トークン漏えい対策が重要
失効や更新の仕組みが必要
保存場所の設計が重要

CookieベースとTokenベースの違い

どちらが絶対に優れているというより、利用形態によって向き不向きがあります。ブラウザ中心か、API中心かで考えると整理しやすいです。

観点	Cookie + Session	Tokenベース
主な利用先	ブラウザWebアプリ	API、SPA、モバイル
認証情報の送信	ブラウザがCookieを自動送信	クライアントが `Authorization` を付与
状態管理	サーバー側Sessionで管理しやすい	ステートレス寄りに設計しやすい
実装のしやすさ	サーバーサイドWebで扱いやすい	APIファースト設計と相性がよい
注意点	CSRF、Cookie属性	トークン保存、失効管理

どちらを選ぶかの目安

サーバーサイドレンダリング中心のWebアプリ → Cookie + Session が自然
SPA + API → Token方式やCookie方式を要件に応じて選ぶ
モバイルアプリ → Token方式がよく使われる
外部公開API → Token方式が一般的

Cookie属性で最低限知るべきこと

Cookieはただ保存するだけではなく、属性によって安全性と送信条件が変わります。特に HttpOnly、Secure、SameSite は重要です。

属性	役割
`HttpOnly`	JavaScriptから参照しにくくする
`Secure`	HTTPS通信でのみ送る
`SameSite`	クロスサイト送信を制御する
`Path`	どのパスで送るかを制御する
`Expires` / `Max-Age`	有効期限を設定する

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

HttpOnly: ブラウザ上のJavaScriptからCookieへアクセスしにくくなり、漏えいリスクを下げます。特にセッションCookieでは重要です。
Secure: HTTPSでのみCookieを送る設定で、平文通信での漏えいリスクを下げます。本番環境では基本的に必要です。
SameSite: クロスサイト経由のCookie送信を制御し、CSRF対策に関わる重要な属性です。Strict（強く制限）、Lax（一部遷移では送る）、None（制限しないが Secure が必要）の3種類があります。

セキュリティで注意したい点

認証は機能要件だけでなく、攻撃耐性も重要です。CookieでもTokenでも、HTTPS前提・漏えい対策・失効管理が基本になります。

最低限意識したい点:

HTTPSを使う
パスワードを平文保存しない
ログイン後にSession IDを再発行する設計を検討する
HttpOnly、Secure、SameSite を適切に使う
トークンやCookieをログに出しすぎない
ログアウトや失効処理を用意する

よくあるリスク

リスク	例	対策の方向性
セッションハイジャック	Cookieが盗まれる	HTTPS、`Secure`、`HttpOnly`
CSRF	意図しない送信が起きる	`SameSite`、CSRF対策
トークン漏えい	ローカル保存情報が盗まれる	保存方法見直し、短寿命化
セッション固定化	攻撃者がSession IDを固定する	ログイン後に再発行する

DevToolsで確認するポイント

認証は目に見えにくいですが、ブラウザ開発者ツールでかなり観察できます。Cookieや Authorization の有無を確認する習慣が重要です。

Networkタブ: Request Headers、Response Headers、Status Code
Applicationタブ: Cookies、Storage関連

確認ポイント:

ログインレスポンスに Set-Cookie があるか
次回リクエストに Cookie が載っているか
API呼び出しに Authorization が付いているか
401 と 403 のどちらが返っているか
HTTPSで送っているか

curl でCookieを使う例:

# ログインしてCookieを保存する
curl -i -c cookies.txt \
  -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "email=test@example.com&password=secret" \
  https://example.com/login

# 保存したCookieを使って再アクセスする
curl -i -b cookies.txt https://example.com/mypage

# Bearerトークンを使う例
curl -i \
  -H "Authorization: Bearer xxxxxx" \
  https://api.example.com/me

よくあるつまずき

症状	原因になりやすい点	確認方法
ログイン直後に未ログイン扱い	`Set-Cookie` が返っていない	ログインレスポンスのヘッダー確認
次の画面でセッションが消える	Cookieが送られていない	次回リクエストの `Cookie` 確認
APIで `401` になる	`Authorization` 不足、期限切れ	Request Headers を確認
管理画面APIで `403` になる	権限不足	ユーザー権限と認可条件を確認
本番だけ動かない	HTTPSやCookie属性の違い	`Secure`、`SameSite`、ドメイン設定を確認

まとめ

HTTPは状態を持たないため、ログインや利用者識別にはCookie、Session、Tokenなどの仕組みが必要です。認証と認可を分けて理解し、Cookie + SessionとToken方式の違いを押さえると、WebアプリとAPIの設計が見通しやすくなります。

認証は「誰か」を確認し、認可は「何をしてよいか」を決める
HTTPはステートレスなので、ログイン状態は追加の仕組みで管理する
Cookieはブラウザ側、Sessionはサーバー側で使われることが多い
APIでは Authorization: Bearer ... を使うToken方式も一般的
Cookie + Session と Token方式にはそれぞれ向き不向きがある
HttpOnly、Secure、SameSite は重要なCookie属性
認証の不具合調査では Set-Cookie、Cookie、Authorization、401、403 を確認する

HTTP認証、Cookie、Sessionの基本

概要