Keycloak vs Microsoft Entra ID: architecture, cost and migration trade-offs
A practical comparison of Keycloak and Microsoft Entra ID for workforce and application identity, including operations, Conditional Access and migration.
- Keycloak
- Security
- Cloud
- Architecture
Keycloak and Microsoft Entra ID can both issue tokens and federate applications, but they solve different ownership problems. Keycloak is software you operate and customise. Entra ID is a managed identity platform tied deeply to Microsoft’s directory, device and security ecosystem. The correct comparison starts with workforce identity versus application identity, not with a single feature grid.
First decide whose identity you are managing
For employees using Microsoft 365, managed devices and Azure, Entra ID is normally the system already holding the identities and signals. Conditional Access can combine user, device, location and risk information; Microsoft documents that the feature requires Entra ID P1, while risk-based controls require P2. Licensing and bundles change, so a static price multiplied by every identity is not a reliable total-cost model.
Keycloak is often a better fit when a product needs its own realms, custom authentication journeys, protocol brokering or deployment inside a controlled environment. It supports OpenID Connect, OAuth 2.0 and SAML, and can federate external directories. “Open source” removes a licence fee for the server; it does not remove the database, compute, patching, on-call and security-review costs.
What each choice makes you own
| Concern | Keycloak | Entra ID |
|---|---|---|
| Availability | You design database, cache, load-balancer and recovery architecture. | Microsoft operates the service; you still design tenant resilience and emergency access. |
| Custom flows | Themes, SPIs and custom authenticators offer deep control but increase upgrade work. | Configuration and supported extension points replace server-level customisation. |
| Contextual access | Policies usually require application logic or extensions. | Conditional Access integrates directory, device and risk signals. |
| Data and operations | Full control and full operational responsibility. | Managed control plane with vendor-defined service boundaries. |
Migration is an application programme
Both platforms commonly issue JWT access tokens; token format is not the decisive migration problem. The difficult parts are issuer and audience changes, claim names, group overage behaviour, role modelling, session lifetime, logout, service identities, consent and policy semantics. Inventory every relying party and every authorization decision before moving users.
A safe migration runs both issuers for a bounded period. Add acceptance tests for discovery metadata, signing-key rotation, refresh, logout, clock skew and emergency access. Migrate low-risk applications first, measure sign-in failures and keep a tested rollback until the last relying party is cut over.
The hybrid pattern—and its cost
Using Entra ID for workforce identity and Keycloak for customer-facing applications can be sensible. Federation avoids duplicating employee passwords, while Keycloak can present product-specific claims and flows. The cost is another trust boundary: map immutable identifiers, document which system owns MFA, prevent federation loops and monitor certificate or key rotation on both sides.
A defensible decision
- Choose Entra ID when workforce identity, Microsoft 365, Intune and Conditional Access are central requirements.
- Choose Keycloak when deployment control, custom flows, protocol brokering or product tenancy outweigh the operating burden.
- Use both only when the boundary is explicit and the federation path has an owner and an SLO.
Build a three-year cost model with licences, environments, engineering time, incident response and migration—not a single per-user number or the word “free”.
Primary sources and further reading
Was this useful?