Auth System Design

Purpose

認証基盤を場当たりに組んで「乗っ取り」「ログインできない」を生むリスクを防ぐ。 auth-boundary-check（既存境界の点検）の上流として、認証・本人確認・セッション戦略を一貫設計する。

Use When

• 新規プロダクト・新機能で認証を新設するとき
• 認証方式（パスワード / パスワードレス / SSO / MFA）を選定するとき
• セッション・トークンの寿命や失効方針を決めるとき
• アカウント回復（パスワード再発行・端末紛失）の経路を設計するとき

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 対象利用者: 想定するユーザー種別と規模（一般 / 管理者 / 外部連携）
• 保護対象: 認証で守りたい資産・操作の重要度
• 制約: 既存基盤・コンプライアンス・UX 要件（わかる範囲で）
• 連携要件: SSO / 外部 IdP / API クライアント認証の有無

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: この認証設計で最も重大な選択は何か
2. 根拠: その論点をそう判断した理由
3. 認証設計表: 認証方式 / 本人確認 / セッション・トークン / 回復経路 の選択と理由
4. 含意: 設計が招く UX・運用・セキュリティ上の影響
5. 改善案: MFA・失効・回復の堅牢化の打ち手
6. 代替案: 別方式（パスワードレス / SSO 委譲 / 短命トークン+更新）
7. 判断材料: 認証設計の確定に必要な人間の確認事項

Review Lens

• 目的妥当性: 認証強度が保護対象の重要度と釣り合っているか
• 範囲の過不足: 過剰な認証摩擦／不足した本人確認がないか
• 中長期リスク: 鍵・トークン漏洩時の被害範囲と失効可能性
• LAB全体との整合性: LMS / 自動化 / B2B 展開の認証要件と整合するか
• 非エンジニア理解可能性: 「どうログインし、どう守るか」を関係者に説明できるか
• 他LLM移植耐性: 判断が特定認証製品の前提に依存していないか

Instructions

1. 保護対象の重要度を整理し、必要な認証強度（要素数・MFA 要否）を決める
2. 認証方式を候補比較し、UX と強度のバランスで選ぶ
3. セッション・トークンの寿命・更新・失効方針を定義する
4. アカウント回復経路を設計し、回復経路が新たな侵入口にならないか点検する
5. 鍵・シークレットの保管と失効手順を secret-management-review と連携して確認する
6. 不明な要件は推測せず、確認事項として明示する

Guardrails

• 「自前で暗号・トークンを発明」を勧めない（実績ある標準に寄せる）
• 認証強度を UX だけの理由で過度に下げない
• 回復経路（パスワード再発行等）の本人確認を省略しない
• 認証設計の最終確定は人間に委ねる

LAB Cross-Check

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。

• 要件: 確定した認証方式・セッション/トークン方針・回復経路
• 成功条件: 認証が想定強度で機能すると判断する基準
• 失敗条件: 乗っ取り・ロックアウトを検知する基準
• 実行範囲: 変更してよい認証・セッション・鍵設定
• 影響範囲: 認証変更が波及する機能・利用者
• ロールバック方針: 認証変更が問題を起こした場合の戻し方
• コスト比較: 認証方式ごとの実装・運用・UX コスト

Further Reading

• auth-boundary-check skill — 設計した認証の権限境界を点検する
• access-control-matrix skill — 認証の上に載る認可マトリクスを設計する
• secret-management-review skill — 認証で使う鍵・トークンの管理を点検する
• audit-log-design skill — 認証・回復イベントの監査ログ
• data-auth-principles.md — データ・認証設計の正本（SoT）