auth-implementation-patterns

認証と認可の実装パターン

業界標準のパターンと最新のベストプラクティスを使用して、安全でスケーラブルな認証・認可システムを構築します。

このスキルを使用する場面

• ユーザー認証システムを実装するとき
• REST または GraphQL API を保護するとき
• OAuth2／ソーシャルログインを追加するとき
• ロールベースアクセス制御（RBAC）を実装するとき
• セッション管理を設計するとき
• 認証システムを移行するとき
• 認証の問題をデバッグするとき
• SSO またはマルチテナンシーを実装するとき

中核となる概念

1. 認証と認可の違い

認証（AuthN）: あなたは誰ですか？

• 本人確認（ユーザー名／パスワード、OAuth、生体認証）
• 資格情報の発行（セッション、トークン）
• ログイン／ログアウトの管理

認可（AuthZ）: あなたは何ができますか？

• 権限のチェック
• ロールベースアクセス制御（RBAC）
• リソースの所有権の検証
• ポリシーの適用

2. 認証戦略

セッションベース:

• サーバーがセッション状態を保存
• Cookie にセッション ID を格納
• 従来型でシンプル、ステートフル

トークンベース（JWT）:

• ステートレスで自己完結型
• 水平スケーリングが可能
• クレームを保存できる

OAuth2／OpenID Connect:

• 認証を委任
• ソーシャルログイン（Google、GitHub）
• エンタープライズ SSO

詳細なパターンと実例

詳細なパターンのドキュメントは references/details.md にあります。上記のナビゲーション階層では不十分な場合は、そのファイルを参照してください。

ベストプラクティス

1. 平文のパスワードを保存しない: 常に bcrypt／argon2 でハッシュ化する
2. HTTPS を使用する: 転送中のデータを暗号化する
3. 短命のアクセストークン: 最大 15〜30 分
4. 安全な Cookie: httpOnly、secure、sameSite フラグ
5. すべての入力を検証する: メール形式、パスワード強度
6. 認証エンドポイントのレート制限: ブルートフォース攻撃を防ぐ
7. CSRF 保護を実装する: セッションベース認証の場合
8. シークレットを定期的にローテーションする: JWT シークレット、セッションシークレット
9. セキュリティイベントをログに記録する: ログイン試行、認証失敗
10. 可能な場合は MFA を使用する: 追加のセキュリティ層

よくある落とし穴

• 弱いパスワード: 強力なパスワードポリシーを適用する
• localStorage 内の JWT: XSS に対して脆弱。httpOnly Cookie を使用する
• トークンの有効期限なし: トークンは期限切れになるべき
• クライアント側のみの認証チェック: 常にサーバー側で検証する
• 安全でないパスワードリセット: 有効期限付きの安全なトークンを使用する
• レート制限なし: ブルートフォースに対して脆弱
• クライアントデータを信頼する: 常にサーバー上で検証する