auth-system-setup
Webアプリケーションで認証や認可の設定をしたい場合に、OAuth連携、セッション管理、役割や権限の設計など、安全なアクセス制御の仕組みを構築するSkill。
📜 元の英語説明(参考)
When the user wants to set up authentication and authorization for a web application. Use when the user mentions "auth," "login," "OAuth," "SSO," "single sign-on," "role-based access," "RBAC," "permissions," "user roles," "access control," "authentication," or "authorization." Covers OAuth 2.0 provider integration, session management, and role/permission architecture. For JWT-specific tasks, see jwt-handler. For security review, see security-audit.
🇯🇵 日本人クリエイター向け解説
Webアプリケーションで認証や認可の設定をしたい場合に、OAuth連携、セッション管理、役割や権限の設計など、安全なアクセス制御の仕組みを構築するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o auth-system-setup.zip https://jpskill.com/download/14658.zip && unzip -o auth-system-setup.zip && rm auth-system-setup.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/14658.zip -OutFile "$d\auth-system-setup.zip"; Expand-Archive "$d\auth-system-setup.zip" -DestinationPath $d -Force; ri "$d\auth-system-setup.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
auth-system-setup.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
auth-system-setupフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Auth System Setup
概要
Webアプリケーション向けの完全な認証および認可システムを設計・実装します。OAuth 2.0プロバイダの統合(Google、GitHub、Microsoft)、セッションおよびトークンの管理、ロールベースアクセス制御(RBAC)、およびパーミッションアーキテクチャを網羅します。本番環境で使用できるコード、データベースマイグレーション、およびテストを生成します。
手順
1. 要件の収集
コードを生成する前に、以下を決定します。
- Tech stack: バックエンドフレームワーク、データベース、フロントエンドフレームワーク
- Auth method: OAuthプロバイダ、メール/パスワード、マジックリンク、またはそれらの組み合わせ
- Roles needed: どのようなロールが存在するか?各ロールは何ができるか?
- Token strategy: ステートレスJWT、サーバーサイドセッション、またはハイブリッド
- Compliance: GDPR、SOC 2、HIPAA — データストレージとロギングに影響
2. Authアーキテクチャの設計
認証フロー図とデータモデルを作成します。
- User table: id, email, name, avatar, provider, provider_id, created_at
- Role table: id, name, description
- Permission table: id, resource, action (read/write/delete)
- Role-Permission mapping: role_id, permission_id
- User-Role mapping: user_id, role_id
- Refresh token table: id, user_id, token_hash, family_id, expires_at, revoked_at
3. OAuthフローの実装
各OAuthプロバイダに対して:
- プロバイダ構成を作成します(client ID、secret、scopes、callback URL)
- stateパラメータとPKCEを使用して、認証リダイレクトを実装します
- コールバックを処理します:コードをトークンと交換し、ユーザープロファイルを抽出します
- ユーザーレコードをプロビジョニングまたは更新します
- アプリケーションのトークン(access + refresh)を発行します
パブリッククライアントには常にPKCEを使用してください。常にstateパラメータを検証してください。
4. RBACの実装
パーミッションチェックミドルウェアを生成します。
authorize(resource, action) → middleware function
1. リクエストからユーザーを抽出します(JWTまたはセッション経由)
2. ユーザーのロールとパーミッションをロードします(TTLでキャッシュ)
3. 必要なパーミッションを付与するロールがあるかどうかを確認します
4. 拒否された場合は、明確なエラーとともに403を返します
行レベルのセキュリティのために、所有権フィルタを追加します。
filterByOwnership(resource) → middleware function
1. ユーザーロールがワイルドカードアクセスを持っている場合は、フィルタをスキップします
2. それ以外の場合は、WHERE句を追加します:resource.owner_id = user.id
3. SELECT、UPDATE、DELETEクエリに適用します
5. テストの生成
以下のテストを作成します。
- OAuthフロー:ログイン成功、無効なstate、期限切れのコード
- トークンライフサイクル:発行、リフレッシュ、ローテーション、失効
- RBAC:各ロールが許可されたリソースと拒否されたリソースにアクセスする
- エッジケース:期限切れのトークン、失効したリフレッシュトークン、セッション中のロールの変更
例
例 1: Express + PostgreSQL + Google OAuth
Prompt: 「Expressアプリ用にJWTトークンでGoogle OAuthを設定してください。adminとuserのロールが必要です。」
Output:
auth/providers/google.ts— OAuth 2.0 + PKCEフローauth/middleware/authenticate.ts— JWT検証auth/middleware/authorize.ts— ロールチェッカーmigrations/001_auth_tables.sql— Users, roles, permissions, refresh_tokensauth/services/token.service.ts— リフレッシュローテーションによるJWT発行auth/routes.ts— /auth/google, /auth/callback, /auth/refresh, /auth/logouttests/auth.test.ts— 18件の統合テスト
例 2: Django + GitHub OAuth + マルチテナントRBAC
Prompt: 「DjangoアプリにGitHubログインを追加してください。各組織には独自のロールがあります:owner、editor、viewer。」
Output:
accounts/providers/github.py— django-allauth経由のOAuth統合accounts/models.py— Organization, Membership, Role modelsaccounts/permissions.py— 組織ごとのパーミッションバックエンドaccounts/middleware.py— Orgコンテキストミドルウェア(サブドメインまたはヘッダーから)accounts/decorators.py— @require_org_role('editor') デコレータmigrations/0001_multi_tenant_auth.py— スキーママイグレーションtests/test_permissions.py— 組織境界を越えた22件のテストケース
ガイドライン
- プレーンテキストのパスワードを保存しないでください — コストファクター12+のbcryptまたはargon2idを使用してください
- 機密クライアントであっても、OAuthフローには常にPKCEを使用してください
- 使用するたびにリフレッシュトークンをローテーションしてください — 再利用を検出してトークンの盗難を特定します
- 短いアクセストークンTTLを設定してください — 15分が標準です
- パーミッションをキャッシュしてください — ロールが変更されたときにリロードし、リクエストごとにリロードしないでください
- 認証イベントをログに記録してください — ログイン、ログアウト、失敗した試行、ロールの変更(監査証跡用)
- 認証エンドポイントをレート制限してください — ログインとトークンのリフレッシュに対するブルートフォース攻撃を防ぎます
- ブラウザのリフレッシュトークンには、httpOnly、Secure、SameSite=StrictのCookieを使用してください
- JWTペイロードに機密データを入れないでください — base64であり、暗号化されていません
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Auth System Setup
Overview
Designs and implements complete authentication and authorization systems for web applications. Covers OAuth 2.0 provider integration (Google, GitHub, Microsoft), session and token management, role-based access control (RBAC), and permission architectures. Generates production-ready code, database migrations, and tests.
Instructions
1. Gather Requirements
Before generating any code, determine:
- Tech stack: Backend framework, database, frontend framework
- Auth method: OAuth providers, email/password, magic links, or combination
- Roles needed: What roles exist? What can each role do?
- Token strategy: Stateless JWT, server-side sessions, or hybrid
- Compliance: GDPR, SOC 2, HIPAA — affects data storage and logging
2. Design the Auth Architecture
Create the auth flow diagram and data model:
- User table: id, email, name, avatar, provider, provider_id, created_at
- Role table: id, name, description
- Permission table: id, resource, action (read/write/delete)
- Role-Permission mapping: role_id, permission_id
- User-Role mapping: user_id, role_id
- Refresh token table: id, user_id, token_hash, family_id, expires_at, revoked_at
3. Implement OAuth Flow
For each OAuth provider:
- Create provider configuration (client ID, secret, scopes, callback URL)
- Implement the authorization redirect with state parameter and PKCE
- Handle the callback: exchange code for tokens, extract user profile
- Provision or update the user record
- Issue application tokens (access + refresh)
Always use PKCE for public clients. Always validate the state parameter.
4. Implement RBAC
Generate the permission-checking middleware:
authorize(resource, action) → middleware function
1. Extract user from request (via JWT or session)
2. Load user roles and permissions (cache with TTL)
3. Check if any role grants the required permission
4. Return 403 with clear error if denied
For row-level security, add ownership filters:
filterByOwnership(resource) → middleware function
1. If user role has wildcard access, skip filter
2. Otherwise, add WHERE clause: resource.owner_id = user.id
3. Apply to SELECT, UPDATE, DELETE queries
5. Generate Tests
Create tests for:
- OAuth flow: successful login, invalid state, expired code
- Token lifecycle: issue, refresh, rotate, revoke
- RBAC: each role accessing allowed and denied resources
- Edge cases: expired tokens, revoked refresh tokens, role changes mid-session
Examples
Example 1: Express + PostgreSQL + Google OAuth
Prompt: "Set up Google OAuth with JWT tokens for my Express app. I need admin and user roles."
Output:
auth/providers/google.ts— OAuth 2.0 + PKCE flowauth/middleware/authenticate.ts— JWT verificationauth/middleware/authorize.ts— Role checkermigrations/001_auth_tables.sql— Users, roles, permissions, refresh_tokensauth/services/token.service.ts— JWT issuance with refresh rotationauth/routes.ts— /auth/google, /auth/callback, /auth/refresh, /auth/logouttests/auth.test.ts— 18 integration tests
Example 2: Django + GitHub OAuth + Multi-tenant RBAC
Prompt: "Add GitHub login to my Django app. Each organization has its own roles: owner, editor, viewer."
Output:
accounts/providers/github.py— OAuth integration via django-allauthaccounts/models.py— Organization, Membership, Role modelsaccounts/permissions.py— Per-organization permission backendaccounts/middleware.py— Org context middleware (from subdomain or header)accounts/decorators.py— @require_org_role('editor') decoratormigrations/0001_multi_tenant_auth.py— Schema migrationtests/test_permissions.py— 22 test cases across org boundaries
Guidelines
- Never store plain-text passwords — use bcrypt with cost factor 12+ or argon2id
- Always use PKCE for OAuth flows, even with confidential clients
- Rotate refresh tokens on every use — detect reuse to identify token theft
- Set short access token TTL — 15 minutes is the standard
- Cache permissions — reload on role change, not on every request
- Log auth events — login, logout, failed attempts, role changes (for audit trail)
- Rate limit auth endpoints — prevent brute force on login and token refresh
- Use httpOnly, Secure, SameSite=Strict cookies for refresh tokens in browsers
- Never put sensitive data in JWT payload — it's base64, not encrypted