Leaving an identity provider: what actually locks you in

Most identity platforms speak OpenID Connect and SAML, so moving from one provider to another looks like a configuration change. In practice, identity migrations are among the slowest dependency changes a product team can take on. The protocols are portable. The identifiers, credentials, federation agreements and custom logic built around them often are not.

Consider a fictional B2B software company. Its customer login runs on a hosted identity service at a subdomain the vendor assigned, three internal applications trust it through OpenID Connect, and a dozen enterprise customers sign in through SAML federation with their own identity providers. The company wants to evaluate a move to self-hosted Keycloak, either now or as a tested exit option.

This article proposes how to scope that evaluation. It is not a report of a client engagement, and the same questions apply when moving between two hosted providers. Protocol references were checked against OpenID Connect Core 1.0, the W3C Web Authentication Level 3 Recommendation of 25 August 2026 and the current Keycloak server administration guide.

inventory what the provider actually holds

Start with a list of everything the identity provider stores or decides, not with the list of features you use. For the example company, that inventory would include:

User records and profile attributes
Subject identifiers already issued to each application
Password hashes and their algorithm parameters
MFA factors: TOTP secrets, WebAuthn credentials, recovery codes
Links to social and enterprise identity providers
OIDC client registrations: redirect URIs, secrets, allowed flows
SAML service provider and identity provider metadata, certificates
Signing keys for issued tokens
Custom logic: hooks, rules, flows, email templates
Active sessions and refresh tokens
Audit and sign-in logs

For each line, record whether it can be exported, in what format, and whether the export is complete. A provider that exports profiles but not credentials changes the migration plan more than any difference in protocol support.

subject identifiers: the dependency inside every application

OpenID Connect defines sub as "a locally unique and never reassigned identifier within the Issuer for the End-User." Used together, sub and iss "are the only Claims that an RP can rely upon as a stable identifier for the End-User" (section 5.7).

That makes the identifier issuer-scoped. A new provider normally has a new issuer and generates new subject values. Every application that keyed its user table on sub now needs a mapping from old identity to new. If the current provider issues pairwise identifiers, each application received a different value for the same person, computed by the provider. The mapping then has to be exported per application rather than derived.

The fix is cheap before a migration and expensive during one:

• Give each user an internal identifier owned by your application, and store the issuer and subject as a linked external identity.
• Record which applications depend on sub directly, including analytics, billing and support tools.
• When migrating, carry the legacy subject into the new provider as an attribute, so applications can resolve old records during a transition period.

password hashes: exportable, compatible, or neither

Whether users must reset their passwords depends on two questions: can the current provider export password hashes, and can the new one verify them.

Keycloak's built-in hashing algorithms are Argon2 (the default outside FIPS deployments) and PBKDF2 variants. For other algorithms, the administration guide points to the server developer guide for adding your own hashing provider; community providers exist for common formats such as bcrypt, and should be reviewed like any other code in the sign-in path. The administration guide notes that "if you change the hashing algorithm, password hashes in storage will not change until the user logs in," so imported hashes can be upgraded to the realm's current algorithm on each user's next successful sign-in.

If the current provider cannot export hashes, the options are narrower:

1. Forced reset. Simple to build, costly in support volume and abandoned sign-ins.
2. Migration on sign-in. The new provider validates a password against the old one at first login, then stores its own hash. Keycloak's User Storage SPI can support this pattern, but only if the old provider offers a supported way to verify a password programmatically. Many hosted services restrict exactly that.
3. Passwordless transition. Move users to email links or passkeys during the migration, and retire passwords rather than moving them.

Ask about hash export before signing an identity contract, not when leaving it. The answer determines which of these plans is available.

passkeys belong to a domain, not to a vendor

WebAuthn credentials are scoped to a Relying Party ID. By default the specification requires the RP ID to be "equal to the origin's effective domain, or a registrable domain suffix of the origin's effective domain" (section 5.11). A passkey created on the login page cannot be used for a different RP ID.

In our example, the hosted login page runs on a vendor-assigned subdomain. Passkeys registered there are bound to a domain the company does not control. Moving to a login page on the company's own domain means every user re-registers.

Level 3 adds related origin requests, which allow a relying party to use one RP ID across a listed set of origins. The list is a JSON document served from the RP ID's own domain at /.well-known/webauthn. That helps a company with several brand domains. It does not help when the RP ID belongs to the vendor, because the company cannot publish that file.

The practical rule: put the login experience on a domain you control from the first day, even while using a hosted provider. Most hosted identity services support custom domains. Doing it early keeps passkeys, cookies and phishing-resistant sign-in portable.

TOTP authenticators have a similar, smaller problem. The shared secret defined in RFC 6238 lives with the provider. If it cannot be exported, users re-enrol their authenticator app. Plan the communication and the recovery path before the cutover, not after.

federation is a coordination problem

Enterprise SAML and OIDC federation is often the longest part of an identity migration, and it has little to do with code. Each enterprise customer configured its own identity provider with your service provider's entity ID, assertion consumer URL and signing certificate. Changing those values means a change request in every customer's IT organization, on their schedule.

Reduce that exposure where you can:

• Use entity IDs and endpoints on your own domain, so they can be preserved across providers or proxied during a transition.
• Keep a register of every federation: customer, protocol, metadata URL, certificate expiry, technical contact.
• Treat certificate rollover as a rehearsal. A team that can roll a signing certificate across all federations without incident can also migrate them.

OpenID Connect clients inside your own organization are easier: redirect URIs, client secrets and the discovery URL change in configuration you control. They still need an owner and a test for each application.

custom logic is the proprietary part

Hosted providers let teams add logic to the sign-in flow: enrich tokens, block risky logins, call internal APIs, sync users to other systems. That code usually runs in the vendor's runtime, against the vendor's API, and has no direct equivalent elsewhere.

List every hook and rule, what it reads, what it writes and which applications depend on its output. Keep the business logic in your own services where possible, and let the identity layer call it through a small, documented interface. For user provisioning between systems, prefer a standard such as SCIM (RFC 7643 and RFC 7644) over a sequence of vendor-specific webhooks.

scope the evaluation with acceptance checks

A useful first deliverable is a migration rehearsal with synthetic users, not a complete migration. For the example company, we would propose these checks:

1. Identifier continuity. An existing user signs in through the new provider and each application resolves the same internal account.
2. Password path. A user with an imported or migrated password signs in, and the stored hash is upgraded to the target algorithm.
3. Passkey path. A user with a passkey either signs in, or follows a documented re-registration flow that cannot be used to take over the account.
4. MFA re-enrolment. A user whose TOTP secret could not be moved is forced through a recovery path that still requires a second factor.
5. Federated sign-in. One enterprise federation works against the new provider using the preserved or proxied endpoints.
6. Custom logic. Tokens carry the same claims the applications depend on, produced by code the company owns.
7. Rollback. The applications can return to the old provider during the transition without losing accounts created in between.

The output is an exit plan with measured gaps, not a promise. Some teams run the rehearsal and decide to stay, with a custom domain, internal user identifiers and an export test added. That is a reasonable result: the dependency is still there, but it is no longer critical.

what to do before any migration

Most of the lock-in described here can be reduced without changing provider:

• Serve login and federation endpoints from your own domain.
• Key application data on internal identifiers, not on sub.
• Test the provider's export, including credentials, once a year.
• Keep custom sign-in logic thin and in your own services.
• Maintain a register of federations and client registrations.

This is what we mean by digital sovereignty in identity: not avoiding hosted providers, but keeping the option to leave one on your own schedule. For wallet-based identity on the same principles, see integrating an EUDI wallet with an existing customer platform.

Our identity engineering practice can run the inventory and the rehearsal with your team. Bring the current provider, the applications that trust it and your federations, and let's map what an exit would take.