Enterprise SSO That Survives IdP Changes

Last updated: September 2026

Identity providers change. Companies migrate from Okta to Entra ID to cut costs. Private equity acquisitions force a switch to the parent company’s IdP. Compliance requirements push a move to on-premises ADFS. Startups outgrow Auth0’s pricing and move to self-hosted Keycloak. Every one of these changes breaks SSO integrations if your applications are wired directly to the IdP.

This guide explains how to architect enterprise SSO so identity provider changes do not cascade into application reconfigurations, how the hub pattern insulates apps from upstream IdP churn, and how to implement it with Skycloak or upstream Keycloak.

The cost of rewiring apps on IdP change

Most applications integrate SSO by trusting a single identity provider directly. The app registers with Okta, pulls Okta’s OIDC discovery document, validates tokens against Okta’s JWKS endpoint, and trusts Okta’s issuer claim. This works until you need to switch to a different IdP.

When the IdP changes, every application must:

Update its OIDC or SAML configuration. New issuer URL, new discovery endpoint, new JWKS URL, new metadata XML.
Register with the new IdP. Create new client credentials, configure redirect URIs, set up claims and scopes.
Update user mappings. The old IdP sent emailAddress, the new one sends email. The old one sent groups as an array, the new one sends space-delimited strings.
Re-deploy. Every app that touched the old IdP config needs a deploy cycle.
Test everything. SSO breaks in production if you miss a redirect URI or a claim name.

Multiply that by the number of applications in your portfolio (10? 50? 200?), and an IdP migration becomes a 6-month project with a coordination spreadsheet and a high-stakes cutover weekend.

The hub pattern: one integration point, swappable backends

The hub pattern inserts an identity broker between your applications and your identity providers. Applications trust the hub, and the hub federates to whichever upstream IdP you configure.

Application -> Identity Hub (Keycloak/Skycloak) -> Identity Provider (Okta, Entra ID, etc.)

What applications see

From the application’s perspective, the hub is the identity provider. The app:

Redirects users to the hub’s OIDC or SAML endpoint (not Okta’s or Entra’s).
Validates tokens against the hub’s JWKS.
Trusts the hub’s issuer claim.

The application never knows about the upstream IdP. It does not care whether the hub is federating to Okta, Entra ID, or a local LDAP directory.

What the hub does

The hub:

Receives authentication requests from applications.
Redirects users to the configured upstream IdP (Okta, Entra ID, etc.).
Receives assertions or tokens from the upstream IdP.
Validates signatures and maps attributes to a consistent schema.
Creates or updates a local user record.
Issues a token or assertion to the application.

When you switch from Okta to Entra ID, you update the hub’s identity provider configuration. Your applications do not change. They still trust the hub, and the hub now points to a different backend.

For federated SSO architecture details, see Federated SSO vs a Single IdP: When You Need an Identity Hub.

Skycloak setup: add and swap identity providers

Skycloak runs upstream Keycloak, so the steps below work on any Keycloak 26.x instance or Skycloak tenant. For Microsoft Entra ID (Azure AD), the fastest path is the built-in recipe wizard.

Step 1: Add the first identity provider

Start with the identity provider you are currently using (Okta, Entra ID, Auth0, etc.).

Recommended: Use the Azure AD SSO recipe (for Entra ID)

For Microsoft Entra ID:

Log into your Skycloak account.
Navigate to Recipes in the left sidebar.
Select Azure AD SSO Integration from the recipe list.
Click Start Recipe.
Follow the guided wizard to connect Entra ID as an OIDC identity provider.

The recipe handles discovery, redirect URIs, and attribute mapping automatically.

Alternative: Direct admin console (for other providers or self-hosted Keycloak)

For OIDC providers (Okta, Google, etc.):

Log into the Keycloak admin console.
Select your realm.
Go to Identity providers > Add provider > OpenID Connect v1.0.
Enter alias, display name, discovery endpoint, client ID, and client secret.
Set Trust email to On and First login flow to first broker login.
Click Add.

For SAML providers:

Go to Identity providers > Add provider > SAML v2.0.
Import the IdP’s metadata XML or URL.
Configure alias, display name, NameID format, and signing settings.
Click Add.

For deeper setup details, see the Keycloak identity providers documentation, the enterprise SSO setup guide, and How to Set Entra ID SAML in Keycloak as an IdP.

Step 2: Configure attribute mappers

Attribute mappers normalize claims from the external IdP into consistent Keycloak attributes. This is critical for IdP portability: when you swap IdPs, you update the mappers, and the rest of your config stays the same.

Go to Identity providers > [your-provider] > Mappers.
Add mappers for the attributes you need:

Attribute	Okta Claim	Entra ID Claim	Keycloak Attribute
Email	`email`	`email`	`email`
First name	`given_name`	`given_name`	`firstName`
Last name	`family_name`	`family_name`	`lastName`
Groups	`groups`	`groups`	`groups`

When you later swap from Okta to Entra ID, you only update these mappers if the new IdP sends claims with different names. The downstream token your applications receive always has the same structure.

Step 3: Point your applications at the hub

Your applications integrate with Keycloak (the hub), not with the upstream IdP.

OIDC apps:

Issuer URL: https://your-realm.skycloak.io/realms/your-realm
Authorization endpoint: https://your-realm.skycloak.io/realms/your-realm/protocol/openid-connect/auth
Token endpoint: https://your-realm.skycloak.io/realms/your-realm/protocol/openid-connect/token
JWKS endpoint: https://your-realm.skycloak.io/realms/your-realm/protocol/openid-connect/certs

SAML apps:

IdP metadata URL: https://your-realm.skycloak.io/realms/your-realm/protocol/saml/descriptor

These URLs never change when you swap upstream IdPs. Your apps are stable.

Step 4: Swap the identity provider (without touching apps)

When you need to switch from Okta to Entra ID:

Add the new IdP (Entra ID) using the same steps as Step 1.
Update the attribute mappers to match Entra ID’s claim names (if different from Okta’s).
Test the new IdP (log in via the Entra ID button to verify it works).
Optional: If you are using kc_idp_hint in your application, update it to point to the new IdP alias (entra-id instead of okta).
Optional: Disable or remove the old IdP once all users have migrated.

Your applications did not change. They still trust the same Keycloak realm, and Keycloak now authenticates users via Entra ID instead of Okta.

For applications using domain routing (see Use kc_idp_hint to Choose Identity Provider in Keycloak), you update the domain-to-IdP mapping in one place (your app’s routing logic or the Organizations feature), and all apps pick up the new IdP automatically.

Migrating users during an IdP change

When you switch IdPs, existing users have accounts linked to the old IdP. Keycloak handles this migration through its First Broker Login flow, which can:

Automatically link accounts by email. If a user [email protected] exists and is linked to Okta, and they now log in via Entra ID with the same email, Keycloak prompts them to confirm the account link.
Silently link accounts based on a trusted attribute. Configure the First Broker Login flow to auto-link on email if both IdPs are trusted. This avoids the user-facing prompt.
Create new accounts. If auto-linking is disabled, Keycloak creates a new account when a user logs in via the new IdP.

For most IdP migrations, you enable auto-linking on email so users seamlessly move from the old IdP to the new one on their next login.

Manual user migration

If you need to migrate users before they log in (e.g., to disable the old IdP immediately), you can:

Export the user list from Keycloak (via the admin API or a database query).
Use the Keycloak admin API to update each user’s federated identity link, replacing the old IdP link with the new one.

This is rarely necessary. Just-in-time migration (automatic linking on next login) works for most scenarios.

Export and backup: portability matters

One reason to use Keycloak as your SSO hub is portability. Keycloak exports to standard JSON, and that export includes:

Realm configuration (clients, roles, scopes).
Identity provider configurations (OIDC, SAML).
User accounts and federated identity links.
Authentication flows and mappers.

If you start on Skycloak and later want to self-host, export the realm and import it into your own Keycloak cluster. If you start with self-hosted Keycloak and want managed hosting, import the realm into Skycloak. Your SSO setup is portable.

For export procedures, see Migrating Self-Hosted Keycloak to Skycloak (the reverse path works the same).

Backup your hub configuration

SSO is a critical path in your infrastructure. Losing your Keycloak configuration means losing access to every application that relies on it. Backup strategy:

Automated realm exports. Schedule daily exports of your realm JSON via the Keycloak admin API.
Version control. Store realm config in git (minus secrets) so you can diff and rollback changes.
Database backups. Back up the underlying database (PostgreSQL or MySQL) that Keycloak uses.

Skycloak includes automated backups as part of managed hosting. For self-hosted Keycloak, see the backup and restore documentation.

Why infrastructure pricing matters for portability

Most IDaaS vendors (Auth0, Okta, Stytch) price per monthly active user (MAU) or per authentication event. When your user base grows, costs grow. When you want to leave, exporting your configuration is difficult or impossible because the vendor uses proprietary extensions.

Skycloak and upstream Keycloak price by infrastructure (pods, CPU, memory), not by user count. Your costs are predictable and scale with technical requirements, not business success. And because Keycloak is open source, your configuration exports cleanly to standard JSON.

This matters for IdP portability: if you are building SSO on a platform that locks you in, you have not actually solved the problem this guide addresses. You have just moved the lock-in from individual apps to the identity platform.

For pricing details, see the Skycloak pricing page.

Frequently asked questions

Why do identity provider changes break enterprise SSO?

Most applications integrate SSO by trusting one identity provider directly (Okta, Entra ID, Auth0, etc.). The app hard-codes the IdP’s endpoints, validates tokens against the IdP’s JWKS, and trusts the IdP’s issuer claim. When the IdP changes, every application must update its configuration, register with the new IdP, re-map attributes, re-deploy, and re-test. The hub pattern avoids this by inserting an identity broker (Keycloak) between apps and IdPs, so apps trust the hub and the hub handles upstream IdP changes.

What is the hub pattern in enterprise SSO?

The hub pattern means applications trust a central identity broker (Keycloak or Skycloak) instead of trusting external identity providers directly. The hub federates authentication to upstream IdPs (Okta, Entra ID, etc.), handles protocol translation and attribute mapping, and issues tokens to applications. When you swap IdPs, you update the hub’s configuration, and applications do not change.

How do I migrate users when switching identity providers?

Keycloak’s First Broker Login flow handles user migration automatically. Configure it to auto-link accounts by email (if both IdPs are trusted), and when users log in via the new IdP, Keycloak links their existing account to the new IdP. Users experience no disruption, and you do not manually migrate accounts unless you need to disable the old IdP immediately.

Can I run multiple identity providers at the same time?

Yes. Keycloak supports multiple identity providers in one realm. You can add Okta, Entra ID, Google, and GitHub simultaneously, and users choose which one to use (or your app routes them via kc_idp_hint or the Organizations feature). This is useful during an IdP migration: run both IdPs in parallel, test the new one, migrate users gradually, then disable the old one.

Is Keycloak configuration portable across hosting environments?

Yes. Keycloak exports to standard JSON (realm config, clients, IdPs, users, flows, mappers). You can export from self-hosted Keycloak and import to Skycloak, or vice versa. Your SSO configuration is not locked to a specific hosting environment or vendor.

Conclusion

Enterprise SSO breaks when identity providers change because most applications trust the IdP directly. The hub pattern insulates applications from upstream IdP churn: apps trust Keycloak (the hub), and Keycloak federates to whichever IdP you configure. When you swap IdPs, you update the hub, and your applications stay stable.

Keycloak (and Skycloak) make this practical because configuration exports to standard JSON, attribute mappers normalize claims across IdPs, and the platform prices by infrastructure (not user count), so portability is not held hostage to vendor lock-in.

For federated SSO architecture, see Federated SSO vs a Single IdP: When You Need an Identity Hub. For a canonical recipe for adding any OIDC or SAML IdP to Skycloak, see Skycloak Identity Providers Recipe. For managed Keycloak hosting with built-in identity provider federation, see Skycloak’s Identity Providers feature or start with the Skycloak documentation.