# How to Migrate from Auth0 to Logto: Complete OIDC and User Import Guide

> Migrate from Auth0 to Logto seamlessly. Redirect OIDC clients and import users with existing passwords via the Management API. Avoid forced resets and simplify your authentication.

- Repository: [Logto/logto](https://github.com/logto-io/logto)
- Tags: migration-guide
- Published: 2026-06-30

---

**You can migrate from Auth0 to Logto by redirecting your OIDC client configuration to Logto's standard endpoints and using the Management API to bulk-import users with their existing PBKDF2 password hashes, eliminating forced password resets.**

Logto is an open-source identity platform (available at `logto-io/logto`) that implements the full OIDC/OAuth 2.1 stack with multi-tenant SaaS support and fine-grained RBAC. Because Logto follows standard OIDC protocols, you can migrate from Auth0 to Logto by reconfiguring application endpoints and transferring user data—including legacy password hashes—via the Admin API.

## Logto Architecture for Auth0 Migration

Understanding Logto's core components helps you map Auth0 concepts directly to their equivalents in the Logto source code.

**OIDC Provider Implementation**
Logto exposes standard discovery endpoints (`/.well-known/openid-configuration`) and token services from `packages/core/src/oidc-provider`. This implementation handles authorization, token issuance, and userinfo requests exactly like Auth0, allowing existing OIDC clients to connect without SDK changes.

**Multi-Tenant Isolation**
Each tenant operates as a separate schema with roles stored in the `organization_role_user_relations` table. The Phase 0.5 migration notes in [`packages/schemas/CHANGELOG.md`](https://github.com/logto-io/logto/blob/main/packages/schemas/CHANGELOG.md) detail how this schema supports SaaS-style boundaries equivalent to Auth0 tenants.

**Password Hash Compatibility**
Logto supports seamless credential migration through PBKDF2 hash verification, as documented in Core changelog entries 3.0.7 and 8.5.9. The system accepts `passwordDigest` and `passwordAlgorithm` parameters via the Management API, enabling you to import Auth0's PBKDF2 hashes directly without forcing users to reset passwords.

**Admin API (Management API)**
Located in `packages/core/src/routes/admin` with the entry point in [`app.ts`](https://github.com/logto-io/logto/blob/main/app.ts), this RESTful interface provides programmatic access to create tenants, configure applications, and execute bulk user imports through the `POST /api/users/import` endpoint.

## Pre-Migration Checklist

Before initiating the migration, verify you have:

- **Auth0 password hashes** exported in PBKDF2 format (Logto supports this algorithm natively as of version 8.5.9)
- **Admin API credentials** for your Logto tenant (generate these in the Logto Console)
- **Redirect URI lists** from your Auth0 applications to replicate in Logto
- **Social provider credentials** (Google, Facebook, Azure AD client IDs/secrets) for connector reconfiguration

## Step-by-Step Migration Process

### Step 1: Provision Your Logto Tenant

Create your Logto environment either through Logto Cloud or by self-hosting the OSS version following the installation guide in the repository root [`README.md`](https://github.com/logto-io/logto/blob/main/README.md). For production migrations, self-hosting provides full control over the database and encryption keys stored in `packages/core/src/oidc-provider`.

### Step 2: Configure OIDC Endpoints

In your Logto Console, create a new Application for each Auth0 client (SPA, web app, native, or machine-to-machine). Copy the generated `client_id` and `client_secret`, then update your application's OIDC configuration to point to Logto's endpoints:

- **Discovery URL**: `https://<your-logto-domain>/.well-known/openid-configuration`
- **Authorization endpoint**: `https://<your-logto-domain>/oidc/authorization`
- **Token endpoint**: `https://<your-logto-domain>/oidc/token`
- **UserInfo endpoint**: `https://<your-logto-domain>/oidc/userinfo`

For Node.js/Express applications using `passport-openidconnect`, update the strategy configuration:

```javascript
const OpenIDConnectStrategy = require('passport-openidconnect').Strategy;

passport.use(
  new OpenIDConnectStrategy(
    {
      issuer: 'https://logto.example.com',
      authorizationURL: 'https://logto.example.com/oidc/authorization',
      tokenURL: 'https://logto.example.com/oidc/token',
      userInfoURL: 'https://logto.example.com/oidc/userinfo',
      clientID: process.env.LOGTO_CLIENT_ID,
      clientSecret: process.env.LOGTO_CLIENT_SECRET,
      callbackURL: 'https://yourapp.com/callback',
      scope: 'openid profile email',
    },
    function (issuer, sub, profile, accessToken, refreshToken, done) {
      // Map Logto profile to your internal user record
      return done(null, profile);
    }
  )
);

```

### Step 3: Import Users with Password Hashes

Enable the password digest migration flag by appending `?includePasswordDigest=true` to your Admin API requests. This exposes the raw hash fields required for credential transfer.

Use the User Import endpoint to push Auth0 user data, specifying `pbkdf2` as the `passwordAlgorithm` to leverage Logto's native PBKDF2 support:

```bash
curl -X POST https://logto.example.com/api/users/import \
  -H "Authorization: Bearer $MANAGEMENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "users": [
      {
        "id": "auth0|123456",
        "primaryEmail": "alice@example.com",
        "passwordDigest": "d2d2d2…",
        "passwordAlgorithm": "pbkdf2"
      }
    ]
  }'

```

If you cannot export password hashes from Auth0, import users without the `passwordDigest` field and trigger Logto's password reset flow to establish new credentials.

### Step 4: Reconfigure Social and Enterprise Connectors

For each social connection in Auth0 (Google, Facebook, Azure AD), enable the corresponding connector in Logto. The connector implementations reside in `packages/connectors/connector-google` and similar directories. Copy your existing OAuth client credentials into the Logto connector configuration to maintain identical authentication flows.

### Step 5: Validate RBAC and Claims

Verify that your access tokens contain the necessary claims (`sub`, `email`, `role`, `organization_id`) by testing the end-to-end flow using Logto's `/demo-app` or your own UI. Map Auth0 roles and permissions to Logto's RBAC system using the roles stored in `organization_role_user_relations`.

### Step 6: Cut Over and Decommission

Once you confirm that login, token refresh, password reset, and social connections function correctly, update your DNS or load balancer to route production traffic to Logto. Monitor the `packages/core/src/oidc-provider` logs for authentication errors, then disable the Auth0 tenant.

## Handling Password Hash Compatibility

**PBKDF2 Algorithm Support**
Logto's core (as noted in [`packages/core/CHANGELOG.md`](https://github.com/logto-io/logto/blob/main/packages/core/CHANGELOG.md) section 8.5.9) natively verifies PBKDF2 hashes, the default algorithm used by Auth0. When importing, set `passwordAlgorithm: "pbkdf2"` to instruct Logto to use the PBKDF2 verifier instead of Argon2 or bcrypt.

**Migration Flag Usage**
The `includePasswordDigest=true` query parameter (introduced in Core changelog 3.0.7) allows the API to return existing password hashes for verification during migration phases, ensuring cryptographic continuity between platforms.

## Summary

- **Logto's OIDC compliance** enables seamless endpoint redirection from Auth0 without client SDK modifications.
- **PBKDF2 password hash support** allows you to migrate from Auth0 to Logto without forcing users to reset passwords.
- **The Management API** (`POST /api/users/import`) accepts bulk user data with `passwordDigest` and `passwordAlgorithm` fields for credential transfer.
- **Multi-tenant architecture** in `packages/schemas` preserves SaaS isolation boundaries through the `organization_role_user_relations` table.
- **Standard connectors** in `packages/connectors/` mirror Auth0's social connection functionality with identical OAuth configurations.

## Frequently Asked Questions

### Can I migrate users without forcing them to reset their passwords?

Yes. Logto supports PBKDF2 password hashes (Auth0's default algorithm) as documented in Core changelog 8.5.9. When calling `POST /api/users/import`, include the `passwordDigest` and set `passwordAlgorithm` to `"pbkdf2"`. Logto will verify these hashes against future login attempts using its internal `PasswordHasher` implementation.

### Do I need to modify my application code to switch from Auth0 to Logto?

No code changes are required if your application uses standard OIDC libraries. You only need to update configuration values (issuer URL, client ID, endpoints) to point to your Logto tenant's `/.well-known/openid-configuration`. The endpoints follow the exact same OAuth 2.1/OIDC specification that Auth0 implements.

### How do I migrate Auth0 Rules and Hooks to Logto?

Auth0 Rules map to Logto's RBAC system and custom claims in access tokens. Configure roles and permissions through the Admin API (routes defined in `packages/core/src/routes/admin`), storing relationships in the `organization_role_user_relations` table. For custom logic, implement webhook-style integrations using Logto's connector framework or trigger external services after token generation.

### Does Logto support the same multi-tenant model as Auth0?

Yes. Logto provides tenant-level isolation where each tenant maintains separate user pools, applications, and roles. The database schema (detailed in [`packages/schemas/CHANGELOG.md`](https://github.com/logto-io/logto/blob/main/packages/schemas/CHANGELOG.md) Phase 0.5 migration) supports this architecture natively, allowing you to import an entire Auth0 tenant as a single Logto tenant with equivalent isolation boundaries.