クッキーとセッションとJWTは何が違う?

初めに

こんにちは！クッキーとセッションとJWTってよく聞くけど、結局何が違うのか疑問に思ったのでまとめてみました。それぞれの種類にも触れながらまとめていきたいと思います！

クッキー(Cookie)について

クッキー(Cookie) とは、ウェブサイトがユーザーのブラウザに一時的に保存する小さなデータのことです。主に、ユーザーの識別、設定の保存、ログイン状態の保持、アクセス解析や広告表示の最適化、などのために使われます。

クッキーの種類(4種類)

1. 有効期限による分類
   • セッションクッキー (Session Cookie)
     • 特徴: 一時的なクッキー。Webブラウザを開いている間だけ有効で、ブラウザを閉じると自動的に削除されます。
     • ログイン状態の一時保持など
   • 永続クッキー (Persistent Cookie)
     • 特徴: 指定された有効期限まで、またはユーザーが手動で削除するまでデバイスに保存され続けます。ブラウザを閉じても消えません。
     • ユーザー設定（言語、テーマなど）の記憶、自動ログイン機能、「次回から表示しない」などの設定保持等。
2. 発行元による分類
   • ファーストパーティクッキー (First-party Cookie)
     • 特徴: ユーザーが訪問しているウェブサイト自身が発行するクッキー。
     • そのサイト自身のログイン状態維持、ショッピングカートの内容保持、サイト内の設定記憶など、
   • サードパーティクッキー (Third-party Cookie)
     • 特徴: 表示されているページとは別のドメインが発行するクッキー。
     • ユーザーの行動追跡や広告の最適化に利用されるが、プライバシー保護の観点から規制が強まっている。

セッション(Session)について

セッションとは、特定のユーザーがWebサイトやアプリケーションを利用している間の一連の操作や状態を管理する仕組みのことです。サーバー側でユーザーの状態を一時的に保存し、ユーザーがページを遷移してもその状態を維持するために用いられます。通常は、「セッションID」 がクッキーに保存されてやりとりされる。

セッション(Session)の種類について

主に次の2つに分けられます。

1. クッキーセッション（クライアントサイドセッション）：セッション情報をクライアント（ブラウザ）のCookieに保存。
2. サーバーセッション（サーバーサイドセッション）：セッションIDのみをCookieに保存し、詳細はサーバー側で管理。セッション情報の保存場所によってさらに分類できる。
   • インメモリ
     • 各アプリケーションサーバーのメモリ上にセッション情報を保存する。
     • メリットは、高速アクセスできかつ実装が簡単である。
     • デメリットは、サーバー再起動でデータが消える。スケールアウト（複数台構成）に弱い。
   • ファイル
     • サーバーのローカルファイルシステムにセッション情報を保存
     • メリットは、再起動してもセッション保持可能。
     • デメリットは、I/Oが遅い。複数サーバーでは共有が難しい。
   • データベース(PostgreSQL等)
     • セッション情報をDBのテーブルに保存する
     • メリットは、永続化でき、複数サーバーでセッション共有しやすい。
     • デメリットは、パフォーマンスが若干低い（クエリが発生するため）
   • 分散キャッシュ
     • セッション情報をRedisなどの高速KVSに保存
     • メリットは、高速なアクセスが可能で永続化とスケーラビリティのバランスが良い。
     • デメリットは、セットアップにやや手間がかかる。

セッションの仕組み

1. ユーザーがログインなどのアクションを起こす
2. サーバーが認証し、セッションを生成
   • サーバーは「この人はユーザーXだ」と認証し、セッションIDを生成。
   • 同時に、ユーザーの情報（ID、権限、期限など）をセッションストアに保存。
3. セッションIDをクッキーにセットして、クライアントに返す
4. クライアントは、以降のリクエストでそのクッキーを毎回送信する
5. サーバーはクッキーのセッションIDを使って、セッションストアから情報を取り出す
6. 必要に応じてセッションを更新 or 無効化（ログアウト）

セッションストアの役割

セッションIDとユーザーの状態を紐づけて保存する「セッションストア」が重要です。
保存先の種類は前述の通り（メモリ、DB、Redisなど）。

JWT (JSON Web Tokens) について

JWT(JSON Web Token) は、ユーザーの認証情報や属性を安全にクライアントとサーバー間でやりとりするためのトークンです。ログイン後、ユーザーを識別するために「サーバーがトークンを発行」し、その後はクライアントがそのトークンを使ってサーバーにアクセスする、という形で使われます。

JWTの構造

JWTは、ドット (.) で区切られた3つの部分から構成されます。

1. Header（ヘッダー）
   • トークンの種類や署名アルゴリズムを定義
2. Payload（ペイロード）
   • ユーザー情報や有効期限など、実際のデータ
3. Signature（署名）
   • 改ざん防止のため、HeaderとPayloadに秘密鍵で署名
   • もしトークンが改ざんされていれば、署名の検証で弾かれる

JWTの使われ方(仕組み)

1. ユーザーがログイン
2. サーバーが認証し、JWTを発行
3. サーバーはJWTをレスポンスとしてクライアントに返す
4. クライアントはJWTをローカルストレージやクッキーに保存
5. クライアントが以降のリクエストで、HTTPヘッダーにJWTを付けて送信
6. サーバーはJWTの署名を検証し、Payloadからユーザー情報を取得

まとめ

クッキーは、Webブラウザに情報を保存する仕組みで、セッションIDなどを保持します。
セッションは、サーバー側でログイン状態などを管理する仕組みで、クッキーで識別されます。
JWTは、ユーザー情報を含んだ署名付きのトークンで、サーバー側で状態を持たずに認証できます。