Migrate from Auth0
Stop paying per-MAU. Idenplane gives you the same features — OAuth 2.0, social login, MFA, organizations — without the cloud bill.
This guide walks through migrating from Auth0 to Idenplane — an open-source, self-hosted Auth0 alternative. Idenplane implements the same standards you already use (OAuth 2.0, OpenID Connect, and SAML 2.0) and maps Auth0’s concepts — tenants, applications, connections, roles, and organizations — onto its own, so the move is mostly exporting users, recreating your clients, and swapping the SDK. Because Auth0 stores passwords as BCrypt hashes it doesn’t export, users set a new password on first login (or continue with social login). The payoff: no per-MAU pricing, full ownership of your identity data, and no vendor lock-in. New to the project? Start with Idenplane vs Auth0.
Before you begin
- An Auth0 Management API token with read access to users, clients, and connections.
- A host for Idenplane (Docker or Kubernetes) plus a PostgreSQL database.
- The Idenplane admin API key, and the OAuth app credentials for any social connections.
- A staging environment to validate login, MFA, and social flows before cutover.
Why migrate from Auth0?
Feature Mapping
| Auth0 | Idenplane | Notes |
|---|---|---|
| Tenant | Realm | Same isolation concept |
| Application (SPA) | Client (public) | PKCE enforced |
| Application (Regular Web) | Client (confidential) | With client secret |
| Application (M2M) | Client (service account) | Client Credentials grant |
| Roles | Roles | Realm and client-level roles |
| Organizations | Organizations | B2B multi-tenancy |
| Social Connections | Identity Providers | OIDC/SAML brokering |
| Enterprise (SAML) | Identity Providers (SAML) | Full SP mode |
| Database Connections | Local Users | Default user store |
| Rules / Actions | Plugins / Webhooks | Event-driven extensions |
| Branding | Realm Theming | Custom login pages |
| Logs | Events / Audit Logs | Login + admin events |
Step-by-Step Migration
Export Auth0 Users
Use the Auth0 Management API to export your users with their metadata and roles.
# Export users via Auth0 Management API
curl -X POST "https://YOUR_DOMAIN.auth0.com/api/v2/jobs/users-exports" \
-H "Authorization: Bearer ${MGMT_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"format": "json",
"fields": [
{"name": "user_id"},
{"name": "email"},
{"name": "name"},
{"name": "user_metadata"},
{"name": "app_metadata"}
]
}'Deploy Idenplane
Start Idenplane and create your realm.
# Start Idenplane
docker compose up -d
# Create a realm matching your Auth0 tenant
curl -X POST "http://localhost:3000/admin/realms" \
-H "x-admin-api-key: ${ADMIN_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"name": "my-app",
"displayName": "My Application"
}'Create OAuth Clients
Recreate your Auth0 Applications as Idenplane clients. Match client IDs where possible.
# Create a client for your SPA
curl -X POST "http://localhost:3000/admin/realms/my-app/clients" \
-H "x-admin-api-key: ${ADMIN_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"clientId": "my-spa",
"name": "My SPA",
"type": "public",
"redirectUris": ["http://localhost:3000/callback"],
"webOrigins": ["http://localhost:3000"]
}'
# Create a client for your API
curl -X POST "http://localhost:3000/admin/realms/my-app/clients" \
-H "x-admin-api-key: ${ADMIN_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"clientId": "my-api",
"name": "My API",
"type": "confidential"
}'Import Users
Import your exported Auth0 users into Idenplane. Since Auth0 uses BCrypt, users will need to set new passwords (or use social login).
# Import users to Idenplane
# Note: Auth0 BCrypt hashes cannot be directly imported.
# Users will receive a password reset email on first login.
curl -X POST "http://localhost:3000/admin/realms/my-app/users" \
-H "x-admin-api-key: ${ADMIN_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"email": "[email protected]",
"firstName": "John",
"lastName": "Doe",
"emailVerified": true,
"requirePasswordReset": true
}'Migrate Social Connections
Recreate your Auth0 Social Connections as Idenplane Identity Providers.
# Add Google as an Identity Provider
curl -X POST "http://localhost:3000/admin/realms/my-app/identity-providers" \
-H "x-admin-api-key: ${ADMIN_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"alias": "google",
"displayName": "Google",
"providerId": "oidc",
"enabled": true,
"config": {
"clientId": "your-google-client-id",
"clientSecret": "your-google-client-secret",
"issuer": "https://accounts.google.com",
"authorizationUrl": "https://accounts.google.com/o/oauth2/v2/auth",
"tokenUrl": "https://oauth2.googleapis.com/token"
}
}'Swap the SDK
Replace the Auth0 SDK with the Idenplane SDK in your application. The API is similar.
// Before: Auth0 SDK
import { Auth0Client } from '@auth0/auth0-spa-js';
const auth0 = new Auth0Client({
domain: 'your-tenant.auth0.com',
clientId: 'my-spa',
redirectUri: window.location.origin,
});
// After: Idenplane SDK
import { IdenplaneClient } from 'idenplane-sdk';
const idenplane = new IdenplaneClient({
url: 'https://auth.example.com',
realm: 'my-app',
clientId: 'my-spa',
redirectUri: window.location.origin + '/callback',
});
// Same methods work!
await idenplane.login();
const user = idenplane.getUserInfo();
await idenplane.logout();Important Notes
- Password hashes: Auth0 uses BCrypt which cannot be directly imported. Users will need to reset passwords or use social login.
- Social logins: Users who authenticated via Google/GitHub can log in immediately if you configure the same OAuth app credentials.
- Rules/Actions: Convert Auth0 Rules to Idenplane Plugins or Webhooks — both support custom logic on auth events.
- Custom domains: Update your DNS to point your auth domain to your Idenplane instance.
- Testing: Run Idenplane in parallel with Auth0 during migration. Test all flows before full cutover.