はじめに
個人開発でAWSのCognitoを使おうと調べていたところ、「JWT」という単語が頻繁に出てきました。
JWTがどのような仕組みなのか、なぜCognitoや他の認証システムで使われるのかを理解するために、
セッションID認証とJWT認証の違いについて整理しました。
1. セッションID認証(サーバー側でセッション管理)
仕組み
-
ユーザーがログイン
- クライアント(ブラウザやアプリ)がユーザー名とパスワードを送信
- サーバーが認証し、セッションID を発行
- セッションIDをクライアントに返し、クッキーに保存
-
APIアクセス時の動作
- クライアントはリクエスト時に、セッションIDを送信
- サーバーはセッションIDを管理し、照合して認証
-
サーバーがセッションを管理
- サーバー側の データベースやメモリ にセッション情報を保存
- ユーザーがログアウトすると、サーバー側のセッションが削除
メリット
- 実装が簡単
- セッションの無効化が可能(ログアウト時にサーバー側で削除)
- セッション情報を変更しやすい(管理画面で強制ログアウト可能)
デメリット
- サーバーの負荷が増える(セッションデータの管理が必要)
- スケールしにくい(ロードバランサー環境ではSticky Sessionが必要)
- 分散システムには不向き(マルチサーバーではセッション共有が必要)
2. JWT認証(トークンベースの認証)
仕組み
-
ユーザーがログイン
- クライアントがユーザー名とパスワードを送信
- サーバーが認証し、JWT(トークン)を発行
- クライアントがJWTをローカルストレージやクッキーに保存
-
APIアクセス時の動作
- クライアントはリクエストヘッダにJWTを含めて送信
- サーバーはJWTを検証し、正しければ認証成功
-
サーバーはセッションを管理しない
- JWTには ユーザー情報(ユーザーID, 権限)と有効期限が含まれる
- サーバー側ではトークンの検証のみ行い、データベース不要
JWTの検証方法
- JWTには 署名 が含まれている
- サーバーは 秘密鍵 または 公開鍵 で署名を検証
- JWTの内容が改ざんされていないか、有効期限が切れていないかチェック
メリット
- ステートレス(サーバー側でデータを持たない) → 負荷が軽い
- スケールしやすい → ロードバランサー環境に最適
- APIに適している → モバイルアプリやSPA(シングルページアプリケーション)で広く利用
デメリット
- ログアウトやトークン無効化が難しい(発行済みトークンは有効期限が切れるまで有効)
- トークンの管理が重要(盗まれると第三者が不正アクセス可能)
- 長いトークンはリクエストサイズを増やす(Authorizationヘッダに入れる場合)
3. セッションID認証 vs JWT認証
項目 | セッションID認証 | JWT認証 |
---|---|---|
管理方式 | サーバー側で管理(DBやメモリ) | クライアント側で管理(トークン) |
スケーラビリティ | スケールしにくい(Sticky Sessionが必要) | スケールしやすい(ステートレス) |
認証時の処理 | サーバーがセッションを照合 | サーバーはJWTを検証するだけ |
ログアウト処理 | サーバー側でセッション削除 | 発行済みトークンは無効化しづらい |
セキュリティリスク | セッションハイジャックのリスク | JWTが漏れると不正アクセスされる |
4. AWSでの使い分け
セッションID認証が向いているケース
- EC2ベースのアプリ(Webアプリなど)
- 従来のサーバーセッションを使ったシステム
- ログアウト機能が重要な場合
→ ALB + EC2 ならセッションID認証が一般的
JWT認証が向いているケース
- API Gateway + Lambda でサーバーレスアプリを作る
- モバイルアプリやシングルページアプリ(SPA)
- マイクロサービスでトークンベース認証をしたい
→ API Gateway + Lambda の環境では JWT の方が適している
5. まとめ
✅ セッションID認証
- サーバーでセッションを管理する
- シンプルだがスケールしにくい
- EC2ベースのWebアプリ向け
✅ JWT認証
- クライアントがトークンを管理する(ステートレス)
- APIやマイクロサービスに適している
- API Gateway + Lambda での認証向け
結論:どちらを選ぶべきか?
➡️ EC2ベースならセッションID、API GatewayならJWT
AWSではサーバーレス(API Gateway + Lambda)が増えているので、JWTが主流 になりつつある。