auth-implementation-patterns

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

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

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

• ユーザー認証システムを実装する場合
• REST または GraphQL API を保護する場合
• OAuth2／ソーシャルログインまたは SSO を追加する場合
• セッション管理または RBAC を設計する場合
• 認証または認可の問題をデバッグする場合

このスキルを使用しない場面

• UI の文言やログインページのスタイル設定のみが必要な場合
• タスクがインフラストラクチャのみで、アイデンティティに関する懸念がない場合
• 認証ポリシーや認証情報の保存方法を変更できない場合

手順

• ユーザー、テナント、フロー、脅威モデルの制約を定義します。
• 認証戦略（セッション、JWT、OIDC）とトークンのライフサイクルを選択します。
• 認可モデルとポリシー適用ポイントを設計します。
• シークレットの保存、ローテーション、ログ記録、監査要件を計画します。
• 詳細な例が必要な場合は、resources/implementation-playbook.md を開きます。

安全性

• シークレット、トークン、認証情報を決してログに記録しないでください。
• 最小権限の原則を適用し、鍵を安全に保存してください。

リソース

• 詳細なパターンと例については、resources/implementation-playbook.md を参照してください。

実施例

入力: Express アプリケーションがユーザーのログインを受け付け、ログイン前のセッション ID を保持しています。同梱のプレイブックを読み、認証情報の検証後にセッションを再生成し、必要なアイデンティティフィールドのみを保存し、古い Cookie が /api/profile にアクセスできないことを確認してください。また、ログイン失敗、ログアウト、ストア障害もテストしてください。期待される結果: ログイン成功時はセッション ID が変更され、ログイン失敗時はアクセスが許可されません。

入力と前提条件

インストールされているフレームワーク／SDK のバージョン、アイデンティティプロバイダー、テナントモデル、認証情報ストア、テスト環境を記録してください。プロジェクト固有のデータベースアダプターとリクエストスキーマを用意してください。例は統合のスケッチであり、実行可能なアイデンティティサービスではありません。

制限事項

• JWT の検証はリソースの所有権を確立しません。読み取りと書き込みの両方でテナントおよびオブジェクトのポリシーを適用してください。
• リフレッシュトークンのローテーションにはアトミックな永続化と並行性テストが必要です。発行の例だけではそれを提供しません。
• Cookie フラグは CSRF 保護の代わりにはならず、セキュアクッキーの動作には実際の HTTPS／プロキシ設定をテストする必要があります。
• プロバイダーの統合とパスワードポリシーは、最新の一次ドキュメントとアプリケーションの脅威モデルに照らして確認する必要があります。