From Microsoft Entra ID to Keycloak

Microsoft Entra ID (formerly Azure AD) gates its best capabilities behind P1/P2 SKUs tied to Microsoft 365 tiers, charging per user across the whole directory. Teams that want open, self-hosted application SSO without the per-seat premium move app authentication to Keycloak. But Entra ID is more than an app IdP, so be precise about scope, this is the one place the migration can be misunderstood.

Be clear about scope first

Entra ID does two jobs:

1. The directory / device & M365 identity plane, it’s the backbone of Microsoft 365, Windows device join, Intune, etc.
2. An application SSO provider (OIDC/SAML) for your other apps.

Keycloak replaces #2 well. It does not replace Entra ID as your Microsoft-365/Windows identity backbone, if you use M365, Entra ID stays for that. So the realistic migration is: move your third-party app SSO to Keycloak (cutting where the per-user app-access premium hurts), while Entra ID may remain for the Microsoft estate. Promising a full Entra ID removal for an M365 shop is the trap.

The trade you are making

You gain a self-hosted OIDC/SAML IdP with no per-app-user premium and no feature paywall. You give up Entra’s turnkey conditional access, identity governance, and the deep Microsoft-ecosystem integration, you’ll rebuild policies in Keycloak’s model and run your own HA deployment.

The cost pressure that pushes teams here is specific to Entra’s model. Its premium capabilities sit in P1 and P2 tiers that are priced per user and often bought as part of Microsoft 365 bundles, so the advanced features you want, richer Conditional Access, identity protection, governance, are gated behind those SKUs and metered across the whole directory. For an organisation whose main use of Entra beyond M365 is app SSO, that premium is being paid on every seat to unlock a slice of functionality. Keycloak removes the per-app-user premium for that SSO, but the deep coupling to the Microsoft ecosystem is exactly what does not come with you, which is why scope discipline matters more here than in any other IAM migration.

Where each piece lands

• Entra tenant (app SSO) → Keycloak realm.
• Enterprise applications (OIDC/SAML) → Keycloak clients.
• Directory → Keycloak user federation from Active Directory via LDAP/Kerberos (keep AD as the source of truth; Keycloak federates rather than copies).
• Conditional Access policies → Keycloak authentication flows (step-up MFA, conditions), this is a re-implementation, not a translation; map each policy’s intent.
• Entra MFA → Keycloak OTP / WebAuthn (passkeys).
• Groups/app roles → Keycloak groups and client roles, surfaced as token claims.

Federating the directory, and the cloud-only gap

The user migration hinges on where your accounts actually originate. In a hybrid estate, on-prem Active Directory is the source of truth and Entra is synced from it. Point Keycloak’s user federation at that AD over LDAP and identities, attributes, and group membership flow in; Kerberos can add desktop SSO. Because authentication delegates to AD, there is no password copy to worry about for those accounts.

The gap to plan for is cloud-only identities: accounts that were created directly in Entra and have no on-prem AD object behind them. There is nothing for Keycloak to federate against, so you provision those users into Keycloak through SCIM or the admin API, and you decide up front how their credentials are set, typically a first-login reset or passwordless enrollment. Get an accurate count of cloud-only accounts early, because it changes both the tooling and the user-comms plan.

Rebuilding Conditional Access as authentication flows

This is the part that is a re-implementation rather than a copy, and it is where Entra migrations differ most from the others. Conditional Access expresses policy as conditions and controls: who, from where, on what device, must satisfy which requirement. Keycloak expresses the same intent as authentication flows, ordered executions marked required, alternative, or conditional, grouped into subflows.

A policy that reads “these users, from outside the corporate network, must complete MFA” becomes a flow with a conditional subflow that triggers step-up based on a user attribute, role, or context. Simple and moderate policies map cleanly. The signals Entra evaluates that Keycloak does not have out of the box, device compliance and Intune posture in particular, are the ones that will not translate; be honest about which policies depend on them, because those are Microsoft-ecosystem features you are choosing to leave behind, not rebuild. Inventory every policy, write down what it enforces and why, and rebuild flows from that intent rather than from the policy screens.

Sequencing the move

1. Deploy Keycloak for production, multiple instances behind a load balancer, external PostgreSQL, tested backup/upgrade.
2. Federate from AD via LDAP so identities and group membership flow in (no password copy needed, auth delegates to AD, or use Kerberos/SSO).
3. Re-register applications as Keycloak clients, recreate each OIDC client or SAML integration, exchange SAML metadata/certificates, set redirect URIs and claim mappers.
4. Rebuild conditional access as Keycloak authentication flows; migrate MFA (users re-enroll OTP/passkeys).
5. Cut over per application by user group, validating login, token claims, group-based authorization, and MFA at each step. Keep Entra as the IdP for any app until its Keycloak client is proven.

Traps to plan around

• AD federation vs cloud-only users. If some identities live only in Entra (cloud-only, no on-prem AD), plan how they reach Keycloak (provision via SCIM/admin API).
• SAML cert/metadata rotation is per-app, schedule it.
• Token claim parity, apps expecting specific Entra claims need matching Keycloak mappers.
• HA + DB sizing is real work; a single Keycloak node is fine for a pilot, not production.

Scope it, then cost it

Entra ID → Keycloak is the right move for third-party app SSO off the per-user premium, federating from AD while Entra may stay for the Microsoft 365/Windows plane. The protocol work (clients, claims, federation) is routine; rebuilding conditional access as auth flows and MFA re-enrollment are the effort. Model your per-user app-SSO savings in the calculator above, and treat them as illustrative until you’ve scoped what stays on Entra and the Keycloak ops you’re taking on.