Auth system design
Skill thinkyou0714/claude-lab-skills/lab-data-auth-ops/skills/auth-system-design
THINK YOU LAB thinking-OS skills for Claude Code — reusable judgment/design/automation/communication skill packs (tech-agnostic, MIT)
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.
What its author says it does
Copied from the file, not written here
認証・アイデンティティの仕組み（認証方式・セッション/トークン・本人確認・回復）をゼロから設計する。新規プロダクト・新規認証導入の設計初動で使う。
SKILL.md
5.2 KB, 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）