Cookieとセッションの違いは？ログイン状態・JWT・安全な管理

ひよこ

Cookieとセッションはどちらを使うか選ぶもの？

ペンギン先生

同じ役割の二択ではないよ。Cookieはブラウザへ情報を保存し、条件に合うHTTP要求へ付けて送る仕組み。セッションは複数の要求を通じて状態を管理する考え方で、セッションIDの受け渡しにCookieを使うことが多いんだ。

ひよこ

ログインしたあとの流れは？

ペンギン先生

サーバー側で状態を管理する例では、認証に成功したら推測しにくいセッションIDを発行する。ブラウザにはCookieでIDを渡し、次の要求で戻ってきたIDからサーバーが状態を探す。パスワードをCookieへ入れて送り続けるわけではないよ。

ひよこ

IDだけなら漏れても大丈夫？

ペンギン先生

そのIDを持つだけで利用者になりすませる場合があるので、重要な秘密だよ。TLSで通信を保護し、ログやURLに出さない。サーバーで期限と権限を確認し、ログアウトや漏えい時に失効できるようにするんだ。

ひよこ

ブラウザを閉じたら必ずログアウトする？

ペンギン先生

セッションCookieは有効期限を指定しないCookieだけれど、ブラウザのセッション復元などの影響もある。Cookieの残り方だけで認証期限を決めないでね。サーバー側でアイドル期限や絶対期限を管理することが大切だよ。

ひよこ

HttpOnlyを付ければXSSは防げる？

ペンギン先生

JavaScriptからCookieを読み取ることを制限できるけれど、XSSそのものを防ぐ属性ではないよ。攻撃コードが利用者のブラウザから要求を送る被害は残る。Secure、SameSiteもそれぞれ役割が違うので、入力・出力処理やCSRF対策と組み合わせよう。

ひよこ

JWTはユーザー情報を暗号化するもの？

ペンギン先生

JWTはクレームを表す形式で、よく使う署名付きJWTは内容を隠さないよ。暗号化するJWEは別の扱いだね。JWTもCookieに保存できるので、CookieとJWTも対立する選択肢ではない。秘密をペイロードへ不用意に入れないでね。

ひよこ

JWTならサーバー側の管理は不要？

ペンギン先生

署名や有効期限、発行者、対象者などの検証は必要だし、早く失効させたいときは追加の状態管理が必要になることもあるよ。セッションIDでもJWTでも、盗まれた有効な認証情報への対策は必要なんだ。

ひよこ

GoogleログインもOAuthで認証するの？

ペンギン先生

OAuth 2.0は基本的には認可の仕組み。OpenID Connectはその上に認証を加え、利用者の身元を検証するための仕組みだよ。外部で認証できた後、自分のサイトでログイン状態をどう維持するかは、さらに別の設計になるんだ。

Cookie・セッション・JWTを役割で整理

Cookie属性だけでは完結しない

• Secure：安全な通信経路で送る条件を付ける。値の暗号化や権限確認ではない。
• HttpOnly：スクリプトによるCookieの読み取りを制限する。XSS全体は防げない。
• SameSite：クロスサイト要求での送信を制限する。値によって動作が違い、ログイン連携にも影響する。

CSRF対策、適切なDomain・Path、有効期限、サーバー側の失効も設計します。ログイン時や権限が変わるときはセッションIDを更新し、セッション固定攻撃を防ぎます。

「ログアウトしたのに使える」を防ぐ

Cookieをブラウザから消すことと、サーバー側でIDやトークンを無効にすることは別です。ログアウト後に以前の認証情報を再利用できないか、期限切れや権限変更が反映されるかを確認します。具体的な期限は一律の分数ではなく、扱う情報と利用体験に応じて決めます。

参考資料

確認日：2026年9月27日。製品の仕様・料金・対応環境は導入時にも確認してください。

• OWASP: Session Management：Cookie属性、期限、セッション更新と失効。

• RFC 7519: JWT：署名・MAC・暗号化の区別。

• OpenID Connect Core：OAuth 2.0上の認証レイヤー。

• MDN: Set-Cookie：Cookie属性とブラウザのセッション復元。