Auth system design
Skill thinkyou0714/claude-lab-skills/lab-data-auth-ops/skills/auth-system-design
認証・アイデンティティの仕組み（認証方式・セッション/トークン・本人確認・回復）をゼロから設計する。新規プロダクト・新規認証導入の設計初動で使う。From its SKILL.md
npx -y skills add thinkyou0714/claude-lab-skills --skill auth-system-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.2 KB, ~2.0k tokens by cl100k_base, as published. Nobody here has run it
Purpose
認証基盤を場当たりに組んで「乗っ取り」「ログインできない」を生むリスクを防ぐ。
auth-boundary-check（既存境界の点検）の上流として、認証・本人確認・セッション戦略を一貫設計する。
Use When
- 新規プロダクト・新機能で認証を新設するとき
- 認証方式（パスワード / パスワードレス / SSO / MFA）を選定するとき
- セッション・トークンの寿命や失効方針を決めるとき
- アカウント回復（パスワード再発行・端末紛失）の経路を設計するとき
Inputs
以下を準備すること。不足している場合は推測せず、不足を明示する。
- 対象利用者: 想定するユーザー種別と規模（一般 / 管理者 / 外部連携）
- 保護対象: 認証で守りたい資産・操作の重要度
- 制約: 既存基盤・コンプライアンス・UX 要件（わかる範囲で）
- 連携要件: SSO / 外部 IdP / API クライアント認証の有無
Output Contract
以下の順で出力すること。順序を変えない。
- 論点: この認証設計で最も重大な選択は何か
- 根拠: その論点をそう判断した理由
- 認証設計表: 認証方式 / 本人確認 / セッション・トークン / 回復経路 の選択と理由
- 含意: 設計が招く UX・運用・セキュリティ上の影響
- 改善案: MFA・失効・回復の堅牢化の打ち手
- 代替案: 別方式（パスワードレス / SSO 委譲 / 短命トークン+更新）
- 判断材料: 認証設計の確定に必要な人間の確認事項
Review Lens
- 目的妥当性: 認証強度が保護対象の重要度と釣り合っているか
- 範囲の過不足: 過剰な認証摩擦／不足した本人確認がないか
- 中長期リスク: 鍵・トークン漏洩時の被害範囲と失効可能性
- LAB全体との整合性: LMS / 自動化 / B2B 展開の認証要件と整合するか
- 非エンジニア理解可能性: 「どうログインし、どう守るか」を関係者に説明できるか
- 他LLM移植耐性: 判断が特定認証製品の前提に依存していないか
Instructions
- 保護対象の重要度を整理し、必要な認証強度（要素数・MFA 要否）を決める
- 認証方式を候補比較し、UX と強度のバランスで選ぶ
- セッション・トークンの寿命・更新・失効方針を定義する
- アカウント回復経路を設計し、回復経路が新たな侵入口にならないか点検する
- 鍵・シークレットの保管と失効手順を
secret-management-reviewと連携して確認する - 不明な要件は推測せず、確認事項として明示する
Guardrails
- 「自前で暗号・トークンを発明」を勧めない（実績ある標準に寄せる）
- 認証強度を UX だけの理由で過度に下げない
- 回復経路（パスワード再発行等）の本人確認を省略しない
- 認証設計の最終確定は人間に委ねる
LAB Cross-Check
| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動処理用の資格情報が過剰権限になっていないか |
| データ / 認証 / ログ | — | セッション・認証失敗・回復操作のログを設計したか |
| 実装 / 運用フロー | — | 鍵・トークン失効の運用手順が存在するか |
| 非エンジニア理解可能性 | — | 認証フローを関係者に説明できるか |
| 会員共有 / 再利用耐性 | — | 認証設計が他機能・他プロダクトに転用できるか |
| 他LLM移植耐性 | — | 判断が特定認証製品に依存していないか |
状態は OK / 注意 / NG / 対象外 で記入すること。
Handoff Notes
施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。
- 要件: 確定した認証方式・セッション/トークン方針・回復経路
- 成功条件: 認証が想定強度で機能すると判断する基準
- 失敗条件: 乗っ取り・ロックアウトを検知する基準
- 実行範囲: 変更してよい認証・セッション・鍵設定
- 影響範囲: 認証変更が波及する機能・利用者
- ロールバック方針: 認証変更が問題を起こした場合の戻し方
- コスト比較: 認証方式ごとの実装・運用・UX コスト
Further Reading
auth-boundary-checkskill — 設計した認証の権限境界を点検するaccess-control-matrixskill — 認証の上に載る認可マトリクスを設計するsecret-management-reviewskill — 認証で使う鍵・トークンの管理を点検するaudit-log-designskill — 認証・回復イベントの監査ログ- data-auth-principles.md — データ・認証設計の正本（SoT）
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.