JWT 認証とセッション認証の違い

Web アプリの認証方式として代表的な「セッション認証」と「JWT 認証」の違いをまとめる。

セッション認証（従来方式）

クライアント: cookie に session_id を保持
サーバー:     session_id → DB/Redis で検索 → ユーザー情報取得

• サーバーが状態を持つ（ステートフル）
• session_id は意味のないランダム文字列。本体はサーバー側のストレージに存在する
• ログアウト時は DB/Redis から削除するだけで即座に無効化できる

JWT 認証

クライアント: cookie or Authorization header に JWT を保持
サーバー:     JWT の署名を秘密鍵で検証するだけ → ユーザー情報はトークン内に含まれている

• サーバーは状態を持たない（ステートレス）
• DB/Redis が不要。署名検証だけでユーザーを識別できる
• JWT の中にユーザー ID・権限・有効期限などが埋め込まれている

比較

	セッション	JWT
サーバー側ストレージ	必要（DB/Redis）	不要（署名検証のみ）
即時無効化	✅ 容易（DBから削除）	❌ 困難
スケールアウト	△ ストア共有が必要	✅ 容易（どのサーバーでも検証可）
向いている用途	SSR Web・管理画面	REST API・SPA・モバイル

JWT のデメリット：即時無効化ができない

セッション方式なら DB から session_id を削除すれば即座に無効化できる。
JWT は有効期限が切れるまで原則として使い続けられる。

対策として：

• トークンの有効期限を短くする（15分〜1時間）
• Refresh Token と組み合わせる
• ブラックリスト（無効化済みトークンのリスト）を Redis に持つ → これだとステートレスの恩恵が半減する

JWT と OAuth の違い

混同しやすいが別物。

用語	役割
JWT	トークンの「形式」。情報を署名付きで格納する仕様
OAuth	“Google/GitHub でログイン” のような第三者認可のフロー

ユーザー ID + パスワード認証に JWT を使うのは普通のやり方で、OAuth は不要。

① ユーザーが /login に ID+パスワードを送る
② サーバーがパスワードを検証し、JWT を発行して返す
③ クライアントは以降のリクエストに JWT を付ける（Authorization: Bearer <token>）
④ サーバーは JWT の署名を検証してユーザーを識別する

OAuth は GitHub/Google 等の外部サービスに認証を委ねる場合に使う。