Leave Okta, Auth0 or Entra without a big bang.
A successful IdP migration is organised coexistence: both providers run side by side, each application moves at its own pace, and the old IdP is switched off last. Here is our method, including the honest answer on passwords.
The three questions that block a migration
Frank answers, before anything else.
What about passwords?
Password hash import is not supported, and we would rather tell you. What works: both IdPs coexist, each user is invited into Obexal and recreates a clean password at first login (NIST-aligned policy), or moves straight to a passkey and leaves passwords behind.
An app-by-app cutover
Obexal federates over OIDC or SAML next to your current IdP. Each application moves individually, gets tested, then goes live. No big bang, no forced downtime.
Downstream provisioning keeps flowing
Outbound SCIM provisions your downstream apps and deprovisions automatically on suspension, with audited failures. Joiners and leavers keep flowing throughout the transition.
The cutover path
Rollback stays available the whole way: as long as the old IdP is alive, any application can point back to it in minutes.
What the move changes
We do not grade competitors. Compare your current situation with what Obexal commits to.
| What you have today | With Obexal | |
|---|---|---|
| Data jurisdiction and hosting | Depends on your provider and your contract | EU: hosted in France, datacenter in the Paris region, EU data residency |
| Open, documented standards | To be checked app by app | OIDC, OAuth 2.1, SAML 2.0 and SCIM 2.0, with a public OpenAPI 3.1 contract |
| AI agent identity | Often generic service accounts | First-class identity per agent: owner, expiry, ceilings, kill switch |
| Reversibility | Worth assessing before you sign | Open standards in and out: you can leave the way you came |
A guide for each starting point
Three origins, one canvas: inventory, map, cut over.
From Okta
Inventory your OIDC and SAML applications, your groups and your MFA policies, then recreate them in Obexal app by app. The guide suggests a cutover order.
From Auth0
Same canvas: OIDC and SAML applications, groups, MFA policies. The guide also covers Google and Microsoft social login, supported natively by Obexal.
From Microsoft Entra
OIDC and SAML applications, groups and MFA policies map onto the same standards. The guide details coexistence with an AD directory over inbound LDAP.
The coexistence plan, in four steps
Indicative, cautious durations: every application estate is different.
1. Import the directory
Provision users over inbound SCIM 2.0 (/scim/v2/Users) or connect your directory over LDAP; groups are recreated in the Obexal directory. Count a few hours to a few days depending on size.
2. Federate side by side
Declare Obexal as an OIDC or SAML provider next to the current IdP and move a first pilot application. One day is often enough for the first app.
3. Invite users, rebuild access
Send invitations (the password is recreated at first login under a NIST-aligned policy, with passkeys offered), and rebuild access rules as versioned policies, simulated against 30 days of real sign-ins before you apply.
4. Provision downstream, then decommission
Turn on outbound SCIM, verify automatic deprovisioning, move the remaining apps, then switch the old IdP off. Most migrations spread over a few weeks, app by app, without rushing.
Who walks with you: Obexal is published by a French company currently being structured; the founder answers directly, from the first inventory to decommissioning. Contact us or call +33 9 84 25 52 61.
What maps across, and how
- Users
- Inbound SCIM 2.0 (/scim/v2/Users) or inbound LDAP/AD
- Groups
- Recreated in the Obexal directory, which manages groups natively
- Applications
- OIDC and SAML 2.0, about 40 connectors plus custom apps
- Passwords
- Not imported: recreated at first login (invitation, NIST-aligned policy), passkeys offered
- Downstream provisioning
- Outbound SCIM 2.0, automatic deprovisioning, audited failures
- Access rules
- Versioned policies, simulation against 30 days of real sign-ins, restore
- MFA
- WebAuthn passkeys, TOTP, email codes, step-up
- Audit
- Immutable audit log, real-time stream, export
Migration FAQ
Can you import our password hashes?
No, and we prefer to be clear about it: hash import is not supported. The method that works is coexistence: each user recreates a password at first Obexal login through an invitation, under a policy aligned with NIST 800-63B (Argon2id hashing, compromised passwords rejected with a check that runs 100% locally). It is also the best moment to offer passkeys.
Do we have to migrate everything at once?
No. Obexal runs next to your current IdP as an OIDC or SAML provider. Move applications one at a time and switch sign-in over only when you are ready.
How do we roll back if something goes wrong?
As long as the old IdP is alive, any application can point back to it in minutes, app by app. That is exactly why decommissioning is the last step, never the first.
How do users and groups get into Obexal?
Users over inbound SCIM 2.0 at /scim/v2/Users, or over LDAP. Inbound SCIM covers the Users resource; groups are managed directly in the Obexal directory.
Does downstream provisioning keep working during the transition?
Yes. Outbound SCIM provisions your downstream applications and deprovisions automatically on suspension, with audited failures, throughout the coexistence period.
How long does a migration take?
It depends on the number of applications and integrations. A first pilot app often moves in a day; most estates spread over a few weeks. We would rather give you a cautious range than a promise.
What does Obexal change for AI agents?
Each agent gets a first-class identity: human owner, expiry, scope ceiling, TTL cap, kill switch and delegation via Token Exchange (RFC 8693). See AI agent identity.
Where is our data hosted, and with which certifications?
Hosted in France, datacenter in the Paris region, EU data residency. No non-EU dependency in the request path, no external CDN, self-hosted fonts. Certifications: not certified ISO 27001, SOC 2 or HDS to date; a documented mapping to ISO 27001:2022 exists and a SecNumCloud roadmap is under way.
Let's organise the cutover.
Describe your estate (applications, directory, constraints): the founder answers directly with a coexistence plan.