insforge-integrations
サードパーティのIDプロバイダーをInsForgeプラットフォームに統合し、Clerkなどの主要な認証サービスの構成ガイドとベストプラクティスを提供します。
npx skills add insforge/agent-skills --skill insforge-integrationsBefore / After 効果比較
1 组Clerkの公式ドキュメントを研究し、OAuthフローとAPI設計を理解し、認証ロジックとセッション管理を繰り返しデバッグします。統合には2〜3日かかります。
InsForgeの統合ガイドを参照し、検証済みの設定とコードテンプレートをコピーし、一般的なエッジケースを処理します。認証統合を2時間で完了します。
insforge-integrations
InsForge Integrations
This skill covers integrating third-party authentication providers with InsForge. Each provider has its own guide under this directory.
Supported Providers
Provider Guide When to use
Clerk Clerk JWT Templates + InsForge RLS Clerk signs tokens directly via JWT Template — no server-side signing needed
Auth0 Auth0 Actions + InsForge RLS Auth0 uses a post-login Action to embed claims into the access token
WorkOS
WorkOS AuthKit + InsForge RLS
WorkOS AuthKit middleware + server-side JWT signing with jsonwebtoken
Kinde Kinde + InsForge RLS Kinde token customization for InsForge integration
Stytch Stytch + InsForge RLS Stytch session tokens for InsForge integration
Common Pattern
All integrations follow the same core pattern:
-
Auth provider signs or issues a JWT containing the user's ID
-
JWT is passed to InsForge via
edgeFunctionTokenincreateClient() -
InsForge extracts claims via
request.jwt.claimsin SQL -
RLS policies use a
requesting_user_id()function to enforce row-level security
Choosing a Provider
-
Clerk — Simplest setup; JWT Template handles signing, no server code needed
-
Auth0 — Flexible; uses post-login Actions for claim injection
-
WorkOS — Enterprise-focused; AuthKit middleware + server-side JWT signing
-
Kinde — Developer-friendly; built-in token customization
-
Stytch — API-first; session-based token flow
Setup
-
Identify which auth provider the project uses
-
Read the corresponding reference guide from the table above
-
Follow the provider-specific setup steps
Usage Examples
Each provider guide includes full code examples for:
-
Auth provider dashboard configuration
-
InsForge client utility with
edgeFunctionToken -
requesting_user_id()SQL function and RLS policies -
Environment variable setup
Refer to the specific references/<provider>.md file for complete examples.
Best Practices
-
All provider user IDs are strings (not UUIDs) — always use
TEXTcolumns foruser_id -
Use
requesting_user_id()instead ofauth.uid()for RLS policies -
Set
edgeFunctionTokenas an async function (Clerk) or server-signed JWT (Auth0, WorkOS, Kinde, Stytch) -
Always get the JWT secret via
npx @insforge/cli secrets get JWT_SECRET
Common Mistakes
Mistake Solution
Using auth.uid() for RLS
Use requesting_user_id() — third-party IDs are strings, not UUIDs
Using UUID columns for user_id
Use TEXT — all supported providers use string-format IDs
Hardcoding the JWT secret
Always retrieve via npx @insforge/cli secrets get JWT_SECRET
Missing requesting_user_id() function
Must be created before RLS policies will work
Weekly Installs723Repositoryinsforge/agent-skillsGitHub Stars13First Seen3 days agoSecurity AuditsGen Agent Trust HubPassSocketPassSnykPassInstalled ongemini-cli723antigravity723cline723github-copilot723codex723cursor723
ユーザーレビュー (0)
レビューを書く
レビューなし
統計データ
ユーザー評価
この Skill を評価