Microsoft Entra ID or Keycloak: when each fits
Choose Microsoft Entra ID if your organization is standardized on Microsoft 365 and Azure and you want identity run as a managed cloud service. Choose Keycloak if you need application SSO on infrastructure you control and you have the people to operate it. The decision usually turns on four questions: how deeply sign-in is tied to Microsoft 365, where identity data must physically reside, how much in-house operating capacity you have for a stateful identity service, and which Entra ID P1 or P2 features your policies actually depend on. A renewal notice or a licensing change often triggers the review, but these four answers should drive it.
Entra ID fits best when Microsoft 365 and Azure are the center of your estate, because Exchange Online, Teams and SharePoint sign-in already rely on it and cannot move to Keycloak. Keycloak fits best when a large share of the work is sign-in for line-of-business and third-party applications over OpenID Connect, OAuth 2.0 and SAML 2.0, and when the team can run a clustered service with a synchronously replicated database. Keycloak also supports user federation with existing LDAP and Active Directory servers, so the directory can stay where it is while the application login moves. Confirm with your own architects which applications authenticate against Entra ID today and which of those a Keycloak realm can serve without changes to the client configuration.
Before you commit, inventory the Entra ID P1 and P2 features in use, such as Conditional Access policies, risk-based sign-in and identity protection, and map each one to a Keycloak or privacyIDEA control or record it as a gap. Ask your Microsoft account team which of those features are included in the Microsoft 365 plans you already hold, since bundled licensing changes the math. Then decide who will own patching, backup, high availability and upgrades for Keycloak, because a self-hosted identity provider becomes a tier-zero system for every application that depends on it. If the answer to those questions is unclear, a fixed-scope assessment of the current sign-in estate is a sensible first step.
Which option fits which scenario
This table compares Microsoft Entra ID and self-hosted Keycloak across common scenarios, naming the better fit and the condition that drives the choice. Read each row against your own tenant, data location rules and licensing, since the right answer often depends on which Microsoft services your users already rely on.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Microsoft 365 tenant with mostly Microsoft apps | Microsoft Entra ID | Exchange, Teams and SharePoint sign-in depend on the Entra tenant, and Keycloak cannot remove that dependency |
| Non-Microsoft SaaS apps needing OIDC or SAML under data residency rules | Keycloak | Identity data and sign-in logs must stay in a location you choose, and the apps accept OIDC or SAML from Keycloak |
| Air-gapped or sovereign sites with no outbound cloud access | Keycloak with FreeIPA or Samba AD | Entra ID is a cloud service, so isolated networks need an identity stack they run themselves |
| Applications relying on Conditional Access policies | Entra ID (P1 or P2) | Rebuilding each policy in Keycloak authentication flows or privacyIDEA needs a gap review, especially for risk-based rules that need P2 |
| Internal apps with simple MFA and role-based access | Keycloak | Standard login, MFA and group-based roles can be configured in Keycloak without an add-on licence, subject to your own review |
| B2B guest access for partner users in Microsoft apps | Microsoft Entra ID | Guest collaboration in Teams and SharePoint is tied to Entra B2B, so moving it requires separate design work |
| B2B access for partners to self-hosted apps only | Keycloak | Brokering to partner identity providers over OIDC or SAML can cover partner logins if the apps are not Microsoft-based |
| Teams that run their own operations and patching | Keycloak | Upgrades, high availability and database backups become your responsibility, and need a documented runbook and an owner |
How Keycloak covers application SSO
Keycloak is an open source identity and access management server licensed under Apache 2.0. For application teams, the protocol support decides whether an existing app can be pointed at Keycloak without code changes. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, which covers the large majority of web, API and enterprise application sign-in patterns that Entra ID handles today.
- OpenID Connect for modern apps: Single-page apps, mobile apps and backend services can use standard OIDC client registrations, with the redirect URIs and scopes set per client.
- OAuth 2.0 for APIs: Access tokens issued by Keycloak can protect APIs, and the client credentials flow covers service-to-service calls.
- SAML 2.0 for legacy and SaaS apps: Many enterprise SaaS products still expect SAML assertions, so Keycloak can act as the SAML identity provider for those applications.
- Client registration by application owners: Each application needs its own client definition, so inventories of Entra enterprise apps should be mapped to Keycloak clients one by one.
Before planning cutover, list every Entra enterprise application and record its protocol, token claims and signing certificate expectations. Confirm with each vendor that their SAML or OIDC implementation works with Keycloak's defaults.
User federation lets Keycloak authenticate users who stay in an existing directory, so the directory remains the source of truth for accounts and passwords. Keycloak has built-in federation with existing LDAP and Active Directory servers. For organizations moving application SSO off Entra ID while keeping on-premises Active Directory, this is the component that makes a phased move practical.
- LDAP and Active Directory connection: Keycloak binds to the directory and authenticates users against it, and administrators map directory attributes to Keycloak user attributes.
- Group and role mapping: Directory groups can be mapped to Keycloak groups or roles, which drive which applications and permissions a user receives.
- Sync modes: Confirm how imports and periodic syncs handle deleted or disabled accounts before relying on them for leaver processes.
- Coverage limits: Users that exist only in Entra ID, such as cloud-only accounts, are not covered by an on-premises directory connection and need a separate plan.
Confirm the directory topology, service account permissions and password policy ownership with your identity team before testing. Ask your implementation partner to document which attributes sync in each direction.
Identity brokering means Keycloak delegates sign-in to an upstream identity provider and then issues its own tokens to the application. This is how a Keycloak realm can accept sign-in from an external SAML or OIDC provider, including, where the organization has configured it, a Microsoft Entra ID tenant. Brokering lets application teams keep one integration point while the upstream provider changes over time.
- Upstream provider configuration: Each external provider is configured in Keycloak with its endpoints, signing keys and client settings.
- Attribute and claim mapping: Claims from the upstream provider are mapped to Keycloak user attributes and roles on first login and on each login.
- Transitional coexistence: Brokering can let some applications keep trusting Entra ID while others move to Keycloak-issued tokens during a migration.
- Token lifetime and logout: Confirm how sessions end across brokered providers, since single logout behavior differs between protocols and applications.
Test brokered logins with each application's expected claims and error paths. Confirm with the upstream provider's administrators which tenant or application settings apply to Keycloak.
The admin console manages realms, clients, users, roles and sessions, and Keycloak's authorization services add fine-grained, resource-based access control for applications that need it. For security teams, this is where access decisions are made and reviewed. Keycloak has no Entra ID P1 or P2 equivalent by default, so Conditional Access rules, risk-based sign-in and similar policies must be built, confirmed or replaced in your own environment.
- Realm and client administration: Separate realms can isolate environments or business units, and clients hold the per-application settings.
- Role-based access: Realm and client roles, plus groups, give application owners a model for permissions.
- Fine-grained authorization services: Resources, scopes and policies can express access rules beyond simple roles, and their use should be scoped to applications that need them.
- Authentication flows: Login flows, including MFA steps, are configured in the console and must be tested against each client.
List every Entra Conditional Access policy in use and map each one to a Keycloak flow, a privacyIDEA policy or a gap. Confirm with your security team that any risk-based control has an approved alternative before retiring it.
Capability comparison: Entra ID and Keycloak
This table sets Microsoft Entra ID against self-hosted Keycloak for application single sign-on, with gaps marked where Keycloak does not replace an Entra capability. Entra licensing changes often, so confirm each Entra tier and add-on with Microsoft before you decide, and read the Keycloak column as what the open-source project provides before your own build work.
| Capability | Microsoft Entra ID | Keycloak (self-hosted) |
|---|---|---|
| Protocols | OpenID Connect, OAuth 2.0 and SAML 2.0 for enterprise and Microsoft apps | OpenID Connect, OAuth 2.0 and SAML 2.0 under Apache 2.0 |
| Directory sync and federation | Cloud directory with Entra Connect sync from on-premises Active Directory | Built-in user federation with existing LDAP and Active Directory servers, with Keycloak as the login front end |
| Identity brokering | External identity providers configured per tenant | Identity brokering to external OIDC and SAML providers |
| Conditional Access | Policy engine that requires Entra ID P1, confirm the feature set with Microsoft | No direct equivalent; approximated with custom authentication flows and extensions, which you build and test yourself |
| Risk-based sign-in and identity protection | Risk signals and risk policies that require Entra ID P2, confirm current scope with Microsoft | Gap: no built-in equivalent of Microsoft's risk signals; you must source and integrate these signals |
| Multi-factor authentication | Built-in MFA and passwordless methods managed in the tenant | Built-in OTP and WebAuthn support; certify the methods you need in your own tests |
| B2B and external users | Guest access and cross-tenant collaboration in Entra External ID and B2B settings | Partial: separate realms or brokered logins; cross-organization guest governance needs design work |
| Fine-grained authorization | App roles, groups and Entra-managed entitlements in the tenant | Fine-grained authorization services for resources, scopes and policies |
| Admin tooling and automation | Entra admin center, Microsoft Graph and PowerShell | Admin console, REST admin API and the Keycloak Operator on Kubernetes |
| Audit logging and metrics | Sign-in and audit logs in the Entra portal and through Microsoft's log export options | Admin and event logging you configure; metrics are exposed for your monitoring stack |
| Hosting and data location | Microsoft-operated cloud service in Microsoft's regions | Runs in your cloud account, data center or air-gapped network under your control |
| Microsoft 365 sign-in | Native sign-in for Microsoft 365 and Azure | Cannot replace Microsoft 365 license or sign-in plumbing; Entra stays in the path unless you federate it deliberately |
Where identity data lives and who controls it
Entra ID and Keycloak differ mainly in who operates the identity store and where it sits. The cards below cover the decisions that follow from that difference: tenant location, your own hosting, database choice, the Microsoft 365 dependency, and the evidence you need for compliance reviews.
Entra ID is a Microsoft-hosted service
Entra ID runs as a Microsoft cloud service, and Microsoft chooses where the tenant is placed. You do not operate its databases, patching or availability. Before you decide, ask Microsoft in writing where tenant data, sign-in logs and MFA data are stored and processed, and which regions are involved for your licensing and tenant configuration.
Keycloak runs where you put it
Keycloak is Apache 2.0 software that you deploy in your own cloud account, data center or air-gapped network. The realm data, user credentials and audit events stay on infrastructure your team controls, which is the main reason regulated organizations evaluate it. The trade-off is that your team owns uptime, patching and backups.
Choose a supported production database
Keycloak supports several production databases, including PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Azure SQL. The default dev-file database is for development only. The database holds your identity data, so its location, encryption, backup and replication design become part of the residency review.
Microsoft 365 still depends on Entra ID
Replacing Entra ID for application SSO does not remove Microsoft 365 sign-in, which still runs through Entra ID for the tenant. Exchange, Teams and SharePoint keep their identity data in Microsoft's cloud. Your residency analysis must cover both the Keycloak estate and the Microsoft 365 tenant that remains.
Auditors certify, DeployOpen prepares evidence
Where identity data lives affects which controls an assessor will test, such as access reviews, logging and key management. DeployOpen can prepare the systems, configuration records and evidence for those controls. Independent auditors and certification bodies issue the reports, so confirm with your assessor which evidence they will accept.
Confirm residency terms in writing
Ask Microsoft for its current data residency and processing commitments for your tenant and licensing, and check how they apply to sign-in logs and MFA data. For a self-hosted Keycloak, the terms are the ones your own engineering and legal teams set. Record the answers in the scope agreement before any migration work begins.
The Microsoft 365 sign-in dependency Keycloak cannot remove
Moving application SSO to Keycloak does not remove the Entra ID tenant. Microsoft 365 sign-in, Exchange Online, Teams and most Microsoft desktop and mobile clients still authenticate against Entra ID, and the tenant also holds the directory those services depend on. Before any planning starts, list every Microsoft workload in use and confirm which of them accept a federated sign-in and which require Entra ID as the identity provider for the tenant. Treat Keycloak as the sign-in authority for the applications you move, not as a replacement for the Microsoft 365 identity plane.
There are two broad federation designs to evaluate. In the first, Keycloak fronts applications and Entra ID remains the identity provider for Microsoft services, with each application re-pointed to Keycloak through OIDC or SAML. In the second, an Entra domain is federated to Keycloak over SAML 2.0 so that users sign in to Microsoft services through Keycloak. The second design is possible in some configurations, but it depends on the identity source of truth, the ImmutableID attribute and how user provisioning is handled. Confirm the exact supported design with Microsoft's current federation guidance and with the Keycloak documentation before you commit to a model.
Licensing is the other part you must confirm, because the Microsoft 365 plan, the Entra ID tier and any add-on licenses determine which sign-in features remain available to your users. Ask your Microsoft partner or account team which Microsoft clients and services your tenant uses, which licenses already include Entra ID P1 or P2 functions, and whether a federated design changes any of those entitlements. Record the answers in writing. An illustrative example: if Conditional Access in the tenant still governs Exchange Online sign-in, that policy stays in Entra ID even after Keycloak takes over the internal line-of-business apps.
Cost of ownership by component
This table lists the cost components on each side, who gets paid for each one, whether it is one-time or recurring, and what moves it up or down. Entra ID licensing must be confirmed with Microsoft for your tenant, since no prices are shown here. Keycloak has no license fee, so most of its cost sits in infrastructure, operations and the work of moving applications.
| Cost component | Who is paid, and for what | One-time or recurring, and main drivers |
|---|---|---|
| Entra ID licensing (P1, P2, Entra Suite) | Microsoft, per licensed user under your agreement. Ask your Microsoft account team which plan each user already holds through Microsoft 365 bundles. | Recurring. Driven by user count, which features you need (Conditional Access, risk policies, governance add-ons) and whether licenses are already bundled. |
| Keycloak software | No license fee. Keycloak is licensed under Apache 2.0, so the software itself is free to use. | Not applicable. Cost moves with the components below, plus any paid support subscription you choose, such as the Red Hat build of Keycloak. |
| Servers and hosting | Your cloud account, data center or hardware budget, or a managed platform team you pay. | Recurring. Driven by node count for high availability, environment count (dev, test, production) and the size of your user base. |
| Database | Your database platform or the team that runs it. Keycloak supports PostgreSQL 14 to 18 and several other engines. | Recurring, plus a one-time setup. Driven by licensing of the chosen engine, backup retention and whether you use a managed service. |
| High availability design | Your infrastructure team, and any cluster or network services required. Both supported designs need a synchronously replicated database. | One-time design and test, then recurring. Driven by the number of sites or availability zones and the cost of synchronous replication across them. |
| Upgrades and releases | Your platform team or DeployOpen under a retainer, for testing and rollout of Keycloak releases. | Recurring. Keycloak plans four minor releases a year. Driven by test environments, change control and how many custom extensions you maintain. |
| Support and operations | Your staff on call, a Red Hat subscription if you buy one, or an implementation partner under a retainer. | Recurring. Driven by on-call coverage, monitoring and incident response targets you set. Ask any partner to state response commitments in writing. |
| Moving applications and directories | Your engineers, application owners and any implementation partner, under a fixed scope agreed in writing. | One-time per application wave, plus testing. Driven by the number of SAML and OIDC enterprise apps, custom Conditional Access rules and whether Microsoft 365 sign-in stays on Entra ID. |
What a move from Entra ID to Keycloak involves
The sequence moves application sign-in to Keycloak in controlled waves while Active Directory remains the user source and Microsoft 365 sign-in stays where it is needed. The end state is a tested Keycloak deployment, a documented app inventory, and a clear list of what still depends on Entra ID.
Inventory enterprise applications and their SSO settings
Start by listing every enterprise application registered in Entra ID, with its protocol (SAML or OIDC), redirect URIs, signing certificates, claims, group assignments and whether it uses Conditional Access. The application owner or the identity team does this, usually with an export of the enterprise apps and app registrations from the Entra admin center. You know the step is done when each app has a row with its protocol, owner, user population and the claims it relies on, and every app is marked for migration, retirement or staying on Entra.
Decide the user source and federation path
Decide where users are stored and authenticated before Keycloak is built. In many organizations this is Active Directory, which Keycloak can federate over LDAP through its built-in user federation, so passwords and group membership stay in one directory. The identity team confirms the LDAP attributes, bind account, group mappings and whether any users exist only in Entra ID. Done means a written decision that names the source of truth for each user population and the attributes Keycloak will read.
Stand up Keycloak in a tested high availability design
Build the Keycloak deployment on infrastructure you control, using one of the high availability architectures Keycloak documents and a supported production database with synchronous replication, as the high availability overview requires for its supported designs. The platform team typically handles this, and DeployOpen can plan, implement and harden it under a written scope. Done means failover has been tested, backups are restorable, and the team has agreed how operator updates will be approved, since the Keycloak Operator documentation recommends manual approval mode.
Re-point applications in waves
Move applications to Keycloak in small groups, starting with low-risk internal apps and leaving business-critical or Microsoft-integrated apps for later. For each app, create the Keycloak client, update the SAML entity or OIDC client settings, map claims to match what the app expects, and run a test sign-in with a pilot group. Done means each wave has a rollback plan, an agreed test script, and a sign-off from the app owner that users can sign in and receive the same roles and attributes as before.
Rebuild Conditional Access controls in Keycloak or other tools
Translate each Conditional Access policy into an equivalent control: Keycloak conditional authentication flows, MFA through a second factor provider, or network controls at the edge. Some Entra ID policies, especially those driven by Microsoft risk signals, may have no direct equivalent, so the security team must record each gap and the compensating control. Done means every policy from the inventory has a documented target, a test case, and an accepted residual risk for anything that is not replaced.
Export Entra ID data for reference and rebuild
Download the user list from the Entra admin center (Users, All users, Download users), which provides a CSV that includes attributes such as userPrincipalName, mail, department and on-premises identifiers. Because this export covers users but not application registrations, groups or policies, those must be recreated from the inventory and policy records. Done means the CSV is stored under the organization's retention rules, and the rebuilt apps, groups and policies are reconciled against the inventory.
Plan backups around Keycloak export limits
Keycloak exports and imports realms as JSON files using the kc.sh export and kc.sh import commands. The Keycloak documentation warns that this has limitations as a backup and restore mechanism, and all nodes must be stopped while it runs. Use it for configuration snapshots and migration staging, and rely on a database backup strategy for recovery. Done means the team has tested a restore in a non-production environment, documented the node shutdown window, and confirmed that realm exports alone do not hold every secret or the full state needed for recovery.
Keep Microsoft 365 sign-in on Entra ID where required
Confirm which services still need Entra ID, which typically includes Microsoft 365 and other Microsoft cloud services whose sign-in is tied to the Entra tenant. Keycloak can federate with Entra ID for these scenarios, but this changes who issues tokens for Microsoft services, and the Entra licensing that applies still applies. The identity lead and the Microsoft 365 administrator sign off on the boundary. Done means a written list of Microsoft-dependent services, their licensing status, and a monitoring check for sign-in failures after cutover.
Questions buyers ask before switching from Entra ID to Keycloak
What drives the cost of moving application SSO from Entra ID to Keycloak?
The cost depends mainly on how many applications need to move, how many protocols they use (OIDC, SAML 2.0 or LDAP), and how many Entra ID features the business relies on today. The cost components are the infrastructure to run Keycloak (servers, a supported production database, and high availability), the work of re-pointing each enterprise app, rebuilding policies that Entra ID currently enforces, and ongoing support and upgrades. Infrastructure costs recur. Migration work is largely one-time, though testing and upgrades repeat. Ask for a quote that lists each cost separately, names who performs each task, and states what is excluded.
How long does a Keycloak migration from Entra ID take?
The timeline is set by the scope, not by a fixed duration. The main drivers are the number of applications, how much custom claim mapping or provisioning each app needs, whether Active Directory stays as the user source, the depth of testing required by your change process, and how many environments (development, test, production) must be built. Keycloak's high availability design and database choice also affect how long the platform takes to build and approve. DeployOpen does not publish durations; the written scope sets the schedule, so ask for a timeline tied to named deliverables.
What does the migration require from our internal team?
Expect to name owners for identity, the directory, each business application and the security approval process. Identity owners need to confirm which Entra ID features are in use, including Conditional Access policies, groups, app role assignments and any provisioning. Application owners need to confirm redirect URIs, claims and certificates for each enterprise app. Security and compliance staff need to agree on the controls and evidence the new platform must produce. Your team will also need to schedule a cutover window and approve rollback steps. Confirm these responsibilities in the written scope before work starts.
Can our own engineers run the Keycloak migration without an outside partner?
Many teams with Keycloak and directory experience can handle parts of the work, such as realm configuration or app onboarding. Whether they can run the whole migration depends on their experience with OIDC and SAML 2.0 federation, LDAP or Active Directory integration, high availability, database operations and upgrade planning. A useful self-assessment asks whether the team has already run a Keycloak cluster in production, tested a restore from backup, and rolled back a failed app cutover. Where gaps exist, a fixed-scope engagement can cover only the missing parts, and a retainer can cover support after go-live.
How does Keycloak handle upgrades and database schema changes?
Keycloak migrates its database schema automatically at startup by default, which is convenient for small environments. For larger deployments, the upgrading guide suggests manual migration, where administrators apply the SQL themselves after review. The project plans four minor releases a year and says breaking changes in a minor release are opt-in. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Plan a staging environment, a tested backup and a change window for every upgrade, and confirm your upgrade process and support model in writing.
Do Entra ID Conditional Access rules have direct equivalents in Keycloak?
Some do, and some do not. Keycloak provides conditional authentication flows and role-based access controls that can approximate policies such as step-up authentication for sensitive apps or MFA for administrators. Risk-based sign-in signals that Entra ID P2 derives from Microsoft's own telemetry have no built-in Keycloak equivalent, and device compliance checks depend on what your device management stack provides. Each policy should be mapped one by one, with the gaps recorded and accepted by the risk owner. Ask for that mapping as a deliverable before cutover.
Can Keycloak replace Microsoft 365 sign-in?
Keycloak can take over sign-in for applications that you federate to it, but Microsoft 365 sign-in is tied to Entra ID as the identity provider for the Microsoft tenant. Organizations that want Keycloak to handle sign-in for Microsoft 365 typically federate the Entra domain to Keycloak over SAML 2.0, which requires matching identifiers and provisioning rules, and Entra licensing still applies to the Microsoft 365 services. Clients that rely on modern authentication must be checked against the supported route. Confirm the specific Microsoft clients and licenses in your tenant before committing to this design.
How DeployOpen helps evaluate and implement the switch
DeployOpen plans and implements self-hosted Keycloak inside your own cloud accounts, data centers or air-gapped networks, and helps you test whether moving application SSO off Microsoft Entra ID fits your environment. The work starts with a written scope that separates application SSO from the Microsoft 365 sign-in you keep.
How we scope
- Inventory which SAML and OIDC enterprise apps currently sign in through Entra ID and rank them by risk.
- Confirm which Microsoft 365 and Entra licensing duties stay in place and which move to Keycloak.
- Agree deliverables, timelines and responsibilities in writing before any build work starts.
How we build
- Deploy Keycloak in your environment, connect it to your existing Active Directory over LDAP, and document the realm layout.
- Re-point each application client and rebuild the access rules that replace your Conditional Access policies.
- Test sign-in, MFA step-up, failover and user provisioning per application against the agreed scope.
How we hand over
- Deliver configuration, runbooks and backup procedures that your team can operate without us.
- Document the export and import limits of realm JSON files and the database backup approach you adopt.
- Prepare control evidence for your internal reviews and for the assessments your auditors run, without issuing any attestation ourselves.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan Keycloak upgrades in staged steps, reviewing each minor release before rollout.
- Repeat security testing of the identity layer as applications and access rules change.
