Migrate from Clerk to Faable Auth
Short answer: Migrating from Clerk to Faable Auth means moving from Clerk’s component-first model to a standards-based OAuth 2.0 / OpenID Connect identity server. You recreate your Clerk instance as a Faable Account, your application as one or more Clients, and your social/email connections one-to-one, then export your users from Clerk and import them into Faable. The biggest practical difference is the integration style: instead of Clerk’s prebuilt React components you use standard OAuth flows via @faable/auth-js or a framework quickstart. Teams typically move for European data sovereignty (GDPR), standards portability (no vendor-specific SDK lock-in), and bundling with Faable Deploy.
Concept mapping
| Clerk | Faable Auth | Notes |
|---|---|---|
| Instance (dev/prod) | Account | Your isolated identity boundary |
| Application | Client | SPA, native, regular web, or M2M |
| Social connection / Email & password | Connection | social, database, passwordless |
| Organizations | Teams within an account | Multi-tenant by design |
Prebuilt components (<SignIn/>, <UserButton/>) | Universal Login + your UI | Hosted login screen; build your own UI with the SDK |
| Webhooks | Webhooks | Async events to your backend |
| Backend API / JWT verification | APIs + standard OIDC JWTs | Verify tokens against the JWKS endpoint |
Migration steps
- Create your Account in the Faable Dashboard and note your issuer URL.
- Recreate Connections for each Clerk login method — email/password as a database connection, social as social connections, and magic link / OTP as passwordless.
- Create your Client(s). Most Clerk apps map to a single SPA or regular-web Client; copy your redirect/callback URLs.
- Replace components with flows. Swap Clerk’s React components for the standard Authorization Code + PKCE flow using the SDK. Hosted Universal Login covers the login UI; you keep full control of the rest of your app.
- Export and import users. Export users from Clerk’s Backend API and import them into Faable, including password hashes where available so users don’t reset passwords.
- Verify tokens the standard way. Replace Clerk’s session helpers with standard OIDC JWT verification against Faable’s JWKS endpoint (built into the SDK and quickstarts).
- Cut over behind a flag, then decommission the Clerk instance.
Things that change (and things that don’t)
- No change: your underlying need — sign-up, login, sessions, MFA, social login — all supported.
- Changes: you move from Clerk-specific components to standard OAuth/OIDC flows, which removes SDK lock-in but means building (or restyling) some UI.
Related
- Faable Auth vs Auth0, Clerk & Keycloak
- Get Started with Faable Auth · Clients · Connections
- Quickstart: Next.js
Last updated on
Last updated on