mcpField
A
auth-setup

auth-setup

github.com/get-convexセキュリティ69510 回インストール今日更新
リポジトリ

auth-setup について

Convexで認証、ユーザー管理、アクセス制御を実装するためのスキルです。認証プロバイダーの選択から、プロバイダー別の設定、保護対象の関数やサインインフローの検証まで開発者を案内します。

主な機能

  1. 01認証プロバイダー選定の案内
  2. 02Convex Auth、Clerk、WorkOS、Auth0、独自JWTに対応
  3. 03ID連携とユーザーヘルパーの設定
  4. 04所有権とチーム単位のアクセス制御
  5. 05セットアップと検証のチェックリスト

活用シーン

  1. 01新しいConvexアプリへの認証追加
  2. 02既存の認証プロバイダーの統合
  3. 03所有権やロールに基づくクエリとリソースの保護

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/get-convex/agent-skills --skill auth-setup

インストール後、Claude Code で/auth-setupを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
auth0.md
clerk.md
common-patterns.md
convex-auth.md
workos-authkit.md

詳細

Convex 認証のセットアップ

Convex にユーザー管理とアクセス制御を備えた、安全な認証を実装します。

使用するタイミング

  • 初めて認証をセットアップするとき
  • ユーザー管理（users テーブル、ID のマッピング）を実装するとき
  • 認証ヘルパー関数を作成するとき
  • 認証プロバイダー（Convex Auth、Clerk、WorkOS AuthKit、Auth0、カスタム JWT）をセットアップするとき

最初の手順：認証プロバイダーを選択する

Convex は複数の認証方法をサポートしています。プロバイダーを決めつけないでください。

セットアップコードを書く前に、次の手順を実施してください。

  1. リポジトリを見れば明らかな場合を除き、ユーザーに希望する認証ソリューションを確認します
  2. リポジトリですでにプロバイダーを使用している場合、ユーザーが切り替えを希望しない限り、そのプロバイダーを使い続けます
  3. ユーザーがプロバイダーを選択しておらず、リポジトリを見ても明らかでない場合は、作業を進める前に確認します

よくある選択肢：

  • Convex Auth - 認証を Convex 内で直接処理したい場合の適切なデフォルトです
  • Clerk - アプリですでに Clerk を使用している場合や、Clerk のホスト型認証機能を使いたい場合に使用します
  • WorkOS AuthKit - アプリですでに WorkOS を使用している場合や、特に AuthKit を使いたい場合に使用します
  • Auth0 - アプリですでに Auth0 を使用している場合に使用します
  • カスタム JWT プロバイダー - 上記で対応されていない既存の認証システムと連携する場合に使用します

確認を求める前に、リポジトリ内の次の手掛かりを調べます。

  • @clerk/*、@workos-inc/*、@auth0/*、Convex Auth パッケージなどの依存関係
  • convex/auth.config.ts、認証ミドルウェア、プロバイダーラッパー、ログインコンポーネントなどの既存ファイル
  • 特定のプロバイダーを明確に示す環境変数

プロバイダーの選択後

プロバイダーの公式ガイドと、対応するローカルリファレンスファイルを読みます。

ローカルリファレンスファイルには、具体的なワークフロー、必要なファイルと環境変数、注意点、検証項目が記載されています。

次の項目には、これらの情報源を使用します。

  • パッケージのインストール
  • クライアントプロバイダーの接続
  • 環境変数
  • convex/auth.config.ts のセットアップ
  • ログインとログアウトの UI パターン
  • React、Vite、Next.js 向けのフレームワーク固有のセットアップ

次に、プロバイダーを問わず適用できる Convex 側のパターンについて、references/common-patterns.md を読みます。

  • ctx.auth.getUserIdentity() と users テーブルのマッピング
  • getCurrentUser と getCurrentUserOrNull
  • requireAdmin などの認可ヘルパー
  • 所有権の確認とチームメンバーシップの確認
  • パブリック、プライベート、ハイブリッドなクエリパターン

ドキュメントが参照できる場合、記憶を頼りにプロバイダー固有のセットアップ方法を作り出さないでください。 プロバイダーの初期化コマンドを実行しただけで、連携がすべて完了したと判断しないでください。生成されたファイルを確認し、プロバイダーのリファレンスに記載されている初期化後の接続手順を完了してください。

ワークフロー

  1. ユーザーに尋ねるか、リポジトリから推測して、プロバイダーを特定します
  2. 今すぐローカルのみのセットアップと本番環境対応のセットアップのどちらを希望するか、ユーザーに尋ねます
  3. 該当するプロバイダーのリファレンスファイルを読みます
  4. 現在のセットアップの詳細については、プロバイダーの公式ドキュメントに従います
  5. references/common-patterns.md の共通 Convex パターンを適用します
  6. アプリで users テーブルが必要な場合に限り、storeUser または同等の ID 同期機能を接続します
  7. 必要に応じて、所有者、管理者、チームのアクセス権限を確認します
  8. 求められた場合は、ログイン状態、保護されたクエリ、環境変数、本番環境の設定を確認します

プロバイダーやデプロイのセットアップで対話操作が必要になり、作業が進まなくなった場合は、必要な具体的な手順をユーザーにはっきり尋ね、完了後に作業を続けます。 UI に表示される認証フローについては、セットアップ完了後に実際のサインアップまたはサインインのフローを検証することを提案します。 環境にブラウザー自動化ツールがある場合は、それを使用できます。 ない場合は、ユーザーに簡潔な手動検証チェックリストを提示します。

リファレンスファイル

プロバイダーのリファレンス
  • references/convex-auth.md
  • references/clerk.md
  • references/workos-authkit.md
  • references/auth0.md
共通パターン
  • references/common-patterns.md

チェックリスト

  • セットアップコードを書く前に、適切な認証プロバイダーを選択した
  • 該当するプロバイダーのリファレンスファイルを読んだ
  • ローカルのみのセットアップと本番環境対応のセットアップのどちらを希望するか、ユーザーに尋ねた
  • プロバイダー固有の接続には、プロバイダーの公式ドキュメントを使用した
  • tokenIdentifier インデックスを持つ Users テーブル
  • getCurrentUser ヘルパー関数
  • 初回サインイン用の storeUser ミューテーション
  • すべての保護された関数に認証チェックがある
  • リソースへのアクセスに認可チェックがある
  • 明確なエラーメッセージ（「未認証です」、「権限がありません」）
  • 選択したプロバイダーに合わせてクライアントの認証プロバイダーを設定した
  • 求められた場合は、本番環境の認証セットアップも対象に含めた

コメント

Markdown 対応