コンニチハ
パンに塗り塗りジャム太郎です！
今回のテーマは
「セッション認証」と「JWT」の違い
についてです。
1.はじめに
Webアプリを作っていると、ログイン機能が必要になりますよね。
そのときに出てくるのが「認証」という仕組みです。
でも、「セッション認証」とか「JWT（JSON Web Token）」って、なんか難しそう…
この記事では、初心者の方でもスッと理解できるように、
「セッション認証」と「JWT認証」の違いを図や例を交えてやさしく解説します！
2.「認証」ってなに？
認証とは、「あなたが誰なのかを確認すること」です。
たとえば：
- ログイン画面で「メールアドレスとパスワード」を入力する
- それを使って「この人は本当に登録済みのユーザーか？」をチェックする
これが「認証」です！
3.セッション認証とは？
セッション認証は昔からある、シンプルでよく使われている認証方法です。
流れを簡単に説明すると
- ユーザーがログインする
- サーバー側で「セッションID」を発行して保存する
- クライアント（ブラウザ）はそのセッションIDをCookieに保存する
- 以降のリクエストには、Cookieに入ったセッションIDが自動的に送られる
- サーバーは「保存してあるセッションID」と照らし合わせて、ユーザーを認識する
●イメージ図
[ユーザー] ←ログイン→ [サーバー]
↓保存されたセッションID
[ユーザー] ←→ [サーバー]（毎回IDでチェック）●特徴
- サーバーがユーザー情報を保持している
- クッキーを使う
- セッションはサーバー側で期限切れ管理される
4.JWT認証とは？
JWT（JSON Web Token）は最近よく使われる「トークンベース認証」です。
サーバーにユーザー情報を持たず、すべてをトークンに詰めてクライアントに渡すのが特徴です。
流れを簡単に説明すると：
- ユーザーがログインする
- サーバーはJWT（ユーザー情報を含んだ署名付きのトークン）を発行する
- クライアントはJWTを保存（通常はlocalStorageやCookie）
- 以降のリクエストには、JWTをヘッダーに付けて送信する
- サーバーはそのトークンを検証してユーザーを認識する
●イメージ図
[ユーザー] ←ログイン→ [サーバー]
↓JWT（署名付きのユーザー情報）
[ユーザー] ←→ [サーバー]（毎回JWTを検証）●特徴
- サーバーがユーザー情報を保存しない
- スケーラブル（複数サーバーでも扱いやすい）
- JWT自体に有効期限を持てる
5.まとめ
| 項目 | セッション認証 | JWT認証 |
|---|---|---|
| 状態管理 | サーバーがユーザー状態を保持 | トークンで状態を自己管理 |
| 保存先 | サーバー内メモリ or DB | クライアント（localStorageなど） |
| スケーラビリティ | あまり得意ではない（状態共有が必要） | 得意（サーバーレスでもOK） |
| セキュリティ | CSRFに注意 | XSSに注意 |
| 無効化のしやすさ | サーバー側で削除可能 | 一度発行したJWTは無効にしづらい |
6.結局どっちを使えばいいの？
| ケース | おすすめの認証方法 |
|---|---|
| シンプルなアプリ・サーバー少なめ | セッション認証 |
| モバイルアプリやSPA・API中心 | JWT認証 |
それぞれにメリット・デメリットがあるので、アプリの特性に合わせて選ぶのがベストです！
では、また次の記事で〜