# Auth System Design

> Auth System Design

- Skill: `thinkyou0714/auth-system-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/auth-system-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/auth-system-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/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

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動処理用の資格情報が過剰権限になっていないか |
| データ / 認証 / ログ | — | セッション・認証失敗・回復操作のログを設計したか |
| 実装 / 運用フロー | — | 鍵・トークン失効の運用手順が存在するか |
| 非エンジニア理解可能性 | — | 認証フローを関係者に説明できるか |
| 会員共有 / 再利用耐性 | — | 認証設計が他機能・他プロダクトに転用できるか |
| 他LLM移植耐性 | — | 判断が特定認証製品に依存していないか |

状態は 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](../../../src/lab-data-auth/rules/data-auth-principles.md) — データ・認証設計の正本（SoT）