ユーザー認証の実装パターンと選定基準
認証方式の選択ミスにより、弊社ではセキュリティインシデント発生、システム全体の作り直しで2,400万円のコスト発生したケースがありました。
JWT、セッション、OAuth。それぞれの特性を理解し、システムに最適な認証方式を選ぶことが重要です。
認証方式の比較
| 方式 | 特徴 | メリット | デメリット | 推奨ケース |
|---|---|---|---|---|
| セッション Cookie | サーバーで 状態管理 | • 即座に無効化可能 • サーバー側で制御 | • サーバー負荷 • スケール困難 | 従来型Webアプリ 管理画面 |
| JWT (トークン) | クライアントで 状態管理 | • ステートレス • スケーラブル | • 無効化困難 • サイズ大きい | SPA、モバイルアプリ マイクロサービス |
| OAuth 2.0 | 外部サービス 連携 | • パスワード不要 • 標準プロトコル | • 実装複雑 • 外部依存 | ソーシャルログイン API連携 |
JWT実装の実践
Access Token + Refresh Token パターン
設計:
- • Access Token: 短命（15分）、API呼び出しに使用
- • Refresh Token: 長命（7日）、Access Token再発行に使用
- • Refresh Token はサーバーでも管理（無効化可能に）
実装例:
// ログイン
POST /api/auth/login
{
"email": "[email protected]",
"password": "password123"
}
Response:
{
"access_token": "eyJhbGciOiJ...", // 15分有効
"refresh_token": "dGhpcyBpc...", // 7日有効
"expires_in": 900
}
// Access Token が期限切れになったら
POST /api/auth/refresh
Authorization: Bearer dGhpcyBpc...
Response:
{
"access_token": "eyJhbGciOiJ...", // 新しいトークン
"expires_in": 900
}やってはいけないこと:
- • Access Token の有効期限を長くする（1日以上など）→ 盗まれた時のリスク大
- • JWT に機密情報を含める（パスワード、クレジットカード番号など）
- • サーバー側の署名検証を省略する → 改ざんされる
OAuth 2.0 の実装（Google ログイン例）
// 1. ログインボタンクリック
<a href="https://accounts.google.com/o/oauth2/auth?
client_id=YOUR_CLIENT_ID&
redirect_uri=https://yourapp.com/auth/callback&
response_type=code&
scope=email profile">
Googleでログイン
</a>
// 2. コールバックでコード取得
GET /auth/callback?code=AUTHORIZATION_CODE
// 3. アクセストークンと交換
POST https://oauth2.googleapis.com/token
{
"code": "AUTHORIZATION_CODE",
"client_id": "YOUR_CLIENT_ID",
"client_secret": "YOUR_CLIENT_SECRET",
"redirect_uri": "https://yourapp.com/auth/callback",
"grant_type": "authorization_code"
}
// 4. ユーザー情報取得
GET https://www.googleapis.com/oauth2/v2/userinfo
Authorization: Bearer ACCESS_TOKEN
// 5. 自アプリのセッション作成まとめ
認証方式はシステムの特性に合わせて慎重に選定する必要があります。セッション、JWT、OAuth、それぞれに適したユースケースがあり、間違った選択はセキュリティリスクとコスト増大につながります。
弊社では、適切な認証設計により、セキュリティインシデントをゼロに抑え、ユーザー体験も向上させています。