Keycloak vs midPoint: which to choose

Keycloak vs midPoint: which one does your identity stack need?

If your applications need single sign-on, you need Keycloak, the access management and SSO server. If joiners, movers and leavers are handled by hand and nobody can show who holds which entitlement, you need midPoint, the identity governance and provisioning system. The two solve different problems, and Evolveum is explicit that midPoint is an identity management system, not an SSO server: it is neither an authentication server nor an SSO server, and it provisions accounts into access management systems such as Keycloak instead. Choose Keycloak when the question is how users log in to applications over OpenID Connect, OAuth 2.0 or SAML 2.0. Choose midPoint when the question is who should have which account, who approved it, and whether it was removed on time. Keycloak is licensed under Apache-2.0 with a community release line, while midPoint is licensed under EUPL-1.2 or later and Evolveum states there is no enterprise edition, so licensing will not separate them. Architecture and purpose will.

Most regulated organizations end up needing both, and the decision turns on three questions. First, where are accounts created: in an HR system, an Active Directory domain, or Keycloak itself? Second, where does login happen: at Keycloak, or inside each application? Third, who reviews access: the application owner, a line manager, or an auditor working from certification campaigns? If accounts originate in an authoritative source and must reach several systems, midPoint sits upstream and drives provisioning. If Keycloak is the only place users sign in, a directory or a manual process may be enough to start, and midPoint can come later. Write down the answer to each question for your own environment before you compare products. Then confirm with Evolveum, through the Evolveum FAQ, which connectors and integration patterns fit your target systems, because connector status varies from supported to experimental.

Which platform fits which scenario

This table maps common identity scenarios to the platform that fits best, with the reason tied to what each product does. Keycloak handles login and single sign-on for applications, while midPoint handles account lifecycle and entitlements across target systems. Where a row says both, the two platforms are usually combined rather than chosen between.

Scenario	Better fit	Why
Web apps that need OIDC or SAML login	Keycloak	Keycloak is an access management and SSO server that issues tokens over OpenID Connect, OAuth 2.0 and SAML 2.0. midPoint does not implement the server side of these protocols.
Joiner and leaver process driven by an HR or directory source	midPoint	midPoint is an identity governance platform that provisions and deprovisions accounts in target systems through connectors such as LDAP, Active Directory and Entra ID.
Auditing who holds which entitlement across systems	midPoint	Governance and provisioning are midPoint's core purpose. Confirm the specific certification and reporting features your auditors expect against the current midPoint documentation.
B2B customers managing their own users	Keycloak	Keycloak brokers logins to external OIDC or SAML providers and offers an Organizations feature for B2B tenants. Confirm the delegation model against your customer requirements before committing.
Team already runs Active Directory and needs SSO for web apps	Keycloak	Keycloak federates users from Active Directory and then issues the SSO tokens, so applications do not need direct directory integration. midPoint can also read AD, but it does not handle the login itself.
Lifecycle control over accounts plus web SSO for the same workforce	Both	midPoint keeps accounts correct in directories and applications, and Keycloak authenticates users against those directories. Plan the connection so each system owns a clearly separated responsibility.
Legacy apps that need only an application password store	Neither alone	Neither product replaces an LDAP directory or an application login. Teams often need a directory such as OpenLDAP or FreeIPA with Keycloak in front for SSO.
Passwordless or device-based access to servers and Linux hosts	Neither alone	Keycloak and midPoint do not cover Kerberos host policy or certificates. Consider FreeIPA for Linux identity and confirm host-level requirements separately.

How Keycloak and midPoint are built and deployed differently

Keycloak and midPoint both run as Java-based server platforms, but they depend on different runtime and database choices and scale in different ways. The cards below separate what each platform needs underneath it and who carries the patching, tuning and monitoring work after go-live.

Keycloak needs a relational database

Keycloak requires a relational database in production. Supported options include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL, and the default dev-file database is for development only. Your database team owns backups, sizing and schema changes, and you should confirm which engine your standards already support before choosing.

Keycloak high availability designs

Keycloak documents a single cluster that can span availability zones, a multi-cluster v2 design without an external Infinispan cluster, and the deprecated multi-cluster v1 design. Both supported designs need a synchronously replicated database, so the database network path often decides the topology. Plan ownership of the external load balancer and failover testing before you pick a design.

Keycloak Operator on Kubernetes

The Keycloak Operator installs through Operator Lifecycle Manager, which Keycloak recommends, or with kubectl. It manages Keycloak and realm and client resources, but the database stays outside its scope. Keycloak strongly recommends manual approval mode for operator updates, so someone on your platform team must own each upgrade decision.

midPoint Java runtime versions

midPoint 4.11 and later recommend Java 25 (Java 21 supported), while 4.10 and older recommend Java 21 (Java 17 supported). Your platform team patches the JVM and tracks which midPoint line uses which runtime. Confirm the runtime against the system requirements for your exact release before you schedule a version change.

PostgreSQL repository on a separate server

midPoint uses PostgreSQL as its native repository and recommends a separate database server. Your database administrators own sizing, backups and tuning for the midPoint repository, which holds identities, roles and task state. Keep this database separate from any Keycloak database so that tuning and restores do not affect both at once.

Sticky load balancing and Quartz scheduling

Multi-node midPoint deployments use a sticky HTTP load balancer, a shared central database, cache invalidation between nodes over HTTPS and Quartz for distributed task scheduling. Someone must watch reconciliation and sync task schedules, since a stalled task delays provisioning even when every node looks healthy. Ask Evolveum or your integrator to document which node owns which tasks.

Capability comparison: what each platform does and does not do

This table sets Keycloak's access management features beside midPoint's identity governance and provisioning features, row by row. Read it to see which problem each platform solves, and where a row says to confirm behavior in your own environment before you rely on it.

Capability	Keycloak	midPoint
Primary purpose	Access management and single sign-on for applications and users	Identity governance and administration, provisioning accounts into target systems
Protocols	OpenID Connect, OAuth 2.0 and SAML 2.0 server support	No server side of OAuth 2.0, OpenID Connect or SAML; its own UI can sign in to external SSO
User federation from LDAP or Active Directory	Reads users from LDAP or Active Directory directories	Connects to LDAP and Active Directory through ConnId connectors for account data
Identity brokering	Brokers logins to external OpenID Connect or SAML identity providers	Not a broker; relies on external SSO for its own user interface sign-in
Provisioning to target systems	Limited to its own user store and federated directories; confirm any outbound provisioning need	Provisions through ConnId connectors: LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1
Admin interface	Admin console for realms, clients, users and authorization	Web interface for identity lifecycle, roles and provisioning policy; confirm fit with your approval workflows
Database requirements	Relational database required in production; PostgreSQL 14 to 18, MariaDB, MySQL, SQL Server, Oracle and Aurora PostgreSQL are supported	Native repository is PostgreSQL, ideally on a separate database server
Licensing	Apache-2.0	EUPL-1.2 or later, with no Enterprise Edition
Support model	Community releases plus Red Hat build of Keycloak as a supported distribution; confirm vendor support terms	Evolveum subscriptions for Product Support and Platform Subscriptions; no prices on the page

What the licenses and support models mean for each platform

Keycloak is licensed under Apache-2.0, a permissive license that lets you run, modify and redistribute the server without a commercial agreement with the project. The project is a Cloud Native Computing Foundation incubating project, and its releases are published on the GitHub releases page, where the current release is 26.8.1, published October 13, 2026. Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, and it states that breaking changes in a minor release will be opt-in. That lowers the risk of an unplanned change arriving with a routine update, though you still need to read each release's upgrade notes.

Apache-2.0 terms: You can use, modify and embed the server in your products under the license terms, with no paid edition gating core features.
Community cadence: Four minor releases a year means you must plan regular upgrades, or you will fall behind the supported line.
Opt-in breaking changes: Since 26.0, breaking changes in a minor release are opt-in, which makes staged upgrades easier to schedule.
Red Hat build of Keycloak: This is a separate supported distribution based on the open source project that replaces Red Hat Single Sign-On. It carries Red Hat's support terms and subscription, and it is not the same artifact as upstream Keycloak.
Support choice: Upstream Keycloak has no vendor support contract by default, so you decide whether to rely on in-house skills, a partner or the Red Hat subscription.

Confirm with your legal team which obligations apply to your distribution model, and check the Red Hat product page for the current supported version before you commit to that route.

How Keycloak and midPoint connect in practice

The usual pattern places a directory between the two systems. midPoint writes and removes accounts in that directory through an LDAP or Active Directory connector from the ConnId framework, and Keycloak reads the same directory through its LDAP or Active Directory user federation to authenticate people. midPoint never sees a login, and Keycloak never decides who should exist. Before go-live, confirm which directory your team will use, which midPoint resource and object classes it will manage, and which Keycloak federation mappers will expose the attributes applications need. The directory stays the handoff point, so it needs its own owner and change log.

Passwords and group changes follow different paths. In a federated setup, the password is verified against the directory, so it lives there and not in Keycloak's own user store, and any password policy or lockout rule must be set on the directory side. Group membership changes reach applications only after two steps: midPoint updates group membership in the directory, then Keycloak picks the change up when it next synchronizes users or when a token is issued, depending on how the federation provider is configured. Ask your Keycloak administrator to document the sync schedule and the group-to-role mappers, because a membership change that looks finished in midPoint may not reach an application until the next sync.

Do not assume a direct connector exists. Confirm, for the exact midPoint and Keycloak versions you plan to run, whether a supported Keycloak connector or a SCIM provisioning path is available between them, and whether it covers the account lifecycle you need (create, update, disable, delete). Ask Evolveum and your Keycloak support provider to show that path in writing. The reverse design, where a Keycloak realm acts as the authoritative source and midPoint reads from it, changes who owns the joiner, mover and leaver process and needs its own architecture review before anyone builds it.

Adding midPoint to an existing Keycloak estate, or the reverse

This sequence moves a team from manual account work to governed provisioning in a fixed order, so that the source of truth is settled before any connector is built or any access is changed.

Inventory accounts and entitlements
Platform and identity staff list every account store in use: the Keycloak realm users, any LDAP or Active Directory directory Keycloak federates from, and each application that holds local accounts or role assignments. For each system, record who owns it, how accounts are created and removed today, and which entitlements exist. The step is done when every target system has a named owner and a written account count, and the team can say which accounts were created by hand. This inventory drives every later decision, so gaps found here are cheaper to close than gaps found during the pilot.
Decide the authoritative source
Agree in writing which system is the source of truth for identity attributes and for entitlements. In many estates the HR system or the directory is authoritative, and midPoint sits between that source and the targets. Keycloak remains the place where applications authenticate, so it is usually a provisioning target for accounts and roles rather than the origin of them. Record the decision, the owner of each attribute, and what happens when two systems disagree. The step is complete when the signed decision record exists. Changing this choice after provisioning starts is the most common reason these projects are reworked.
Confirm the directory and connector path
Confirm with Evolveum's connector documentation which connectors fit each target: the LDAP and Active Directory connectors for directories, and the connector status shown in the integration catalog for anything else. Check whether Keycloak's own user store is reachable through a supported connector or whether accounts must reach Keycloak through its federation settings or an API your team builds and supports. Confirm the midPoint runtime requirements for Java and PostgreSQL against your platform standards. The step closes with a connector matrix listing each target, the connector, its support status and the named person who owns the gap.
Pilot provisioning on a non-production directory
Build the first mappings and synchronization rules against a non-production directory or a copied subset of users. Run creation, attribute change and removal cases, including leavers and users with unusual attributes. Compare the results with the source of truth record from the earlier step. The pilot is done when the team has reviewed a set of test runs, every discrepancy has an owner and a fix, and the results are documented. Do not point the pilot at production identities. Keep the pilot environment on the same database and directory versions as production so the results carry over.
Move Keycloak federation settings
Once the pilot is accepted, change the Keycloak side in a planned window. Existing realm configuration, identity brokering settings and client definitions stay in place and are not rebuilt, so the work is mainly the user federation settings and any role mappings that will now come from midPoint. Test sign-in for representative users of each application against a staging Keycloak with a database copy before changing production. The step is done when test sign-in passes for each application and the rollback steps are written down. Keycloak's database schema migration runs automatically at startup by default, so confirm whether your team will use automatic or manual migration before the change.
Retire manual account steps
Switch the manual provisioning runbooks off one system at a time, starting with the systems whose pilots passed cleanly. Keep the manual procedure available for a documented fallback period agreed with the owner of each system. Confirm that every leaver is removed from each target and that access review evidence is produced from midPoint or from the connected systems, as your assessor expects. The step is done when the runbooks are archived, each retired manual step has a sign-off, and a sample of accounts reconciles between source and targets.

What drives the running cost of each platform

Keycloak and midPoint carry different running costs because they solve different problems: one serves logins at high availability, the other reconciles identity data across systems. The cards below separate one-time build work from recurring operations, and show what to put in a quote for each.

Infrastructure footprint

Keycloak needs a production relational database and its HA nodes, and its high availability designs depend on a synchronously replicated database. midPoint runs application servers behind a sticky load balancer with a shared central database, ideally on a separate database server. Ask for the node count, database sizing, backup and failover design each platform needs, and who pays for the cloud or data center capacity under each option.

Java and database skills

Both platforms run on Java and depend on PostgreSQL, so the same operations staff can cover much of the work. midPoint's documented requirements move with its release line, so Java version management is a recurring task. Confirm who on your team owns JVM patching, schema migration and database tuning, and whether that work is in the internal estimate or in an external scope.

Kubernetes Operator skills

If you run Keycloak on Kubernetes, the Operator is installed through Operator Lifecycle Manager or kubectl, and it manages custom resources for realms and clients. Operator knowledge is a distinct skill from identity administration. Ask whether your platform team already operates OLM and custom resources, and whether the Operator's manual approval mode, which the documentation recommends, will be enforced in your change process.

Identity engineering for midPoint

Most midPoint effort sits in designing mappings, roles, correlation rules and connector configuration against your directories and target systems. This work is largely one-time during the build, then recurs when a source system changes or an access policy is revised. Ask a partner to price the connector work, the number of target systems in scope, and the handover of mapping documentation to your team.

Support and subscriptions

Keycloak's upstream project is community-supported, while Red Hat sells a supported distribution of Keycloak under its own subscription. Evolveum sells Product Support and Platform Subscriptions for midPoint, with 8x5 next-business-day or 24x7 response options, and its pages list no prices. Compare the response terms you need against each vendor's current offer, and ask for the subscription cost as a separate line in any quote.

Upgrade cadence and release lines

Keycloak plans four minor releases a year and says breaking changes in minor releases will be opt-in, so routine upgrades recur on a short cycle. midPoint 4.8 is a long-term support line, while 4.10 and 4.11 are feature lines with shorter windows. Choose the line that matches your change capacity, and confirm with the vendor how much test effort each upgrade needs in your environment.

What implementing each involves and where projects run long

Keycloak and midPoint are separate projects with separate work streams, so plan them as two scoped engagements even when they ship together. For Keycloak, the early decisions are the production database (Keycloak needs a relational database in production, and the dev-file default is for development only), the high availability design (a single cluster or the multi-cluster v2 design, both of which need a synchronously replicated database), and whether to run the Keycloak Operator on Kubernetes or the server distribution on virtual machines. The realm and client model follows: which realms exist, how OIDC and SAML clients are registered, which LDAP or Active Directory sources are federated read-only, and which external identity providers are brokered for login. Each of these needs an owner and a written decision before build starts.

For midPoint, the work centers on the data model and mappings: which sources are authoritative for identity attributes, how those attributes map to midPoint users, roles and organizations, and which target systems receive accounts through ConnId connectors such as LDAP, Active Directory, Microsoft Entra ID or SCIM2. Connector configuration, reconciliation runs and the certification and access review processes that prove who holds what are also part of the scope. Confirm the connector status for each target system against the Evolveum connector catalog before you commit to it, because supported, community and experimental connectors carry different levels of vendor assurance. Confirm the Java version and database platform against the midPoint system requirements for the release line you choose.

Projects run long in predictable places. The first is an unclear authoritative source: if HR, the directory and a business application each claim to own a job title, midPoint mappings stall until someone decides. The second is directory cleanup, such as duplicate accounts, stale groups and inconsistent attribute formats in Active Directory or LDAP, which must be fixed before reconciliation produces trustworthy results. The third is undocumented application entitlements: many line-of-business systems hold permissions that no one has written down, and discovering them takes interviews and test accounts. Build those discovery tasks into the fixed scope explicitly. Duration depends on the scope agreed in writing, so ask your implementation partner to tie each of these risks to a named deliverable and an acceptance check.

Questions buyers ask before choosing or hiring help

Can midPoint replace Keycloak as our single sign-on server?

No. Evolveum states that midPoint is an identity management system, not an access management or SSO server, so it does not act as an authentication server and does not implement the server side of OAuth2, OpenID Connect or SAML. Keycloak issues the tokens and assertions your applications trust at sign-in. midPoint's role is to provision accounts, roles and entitlements into systems such as Keycloak, Active Directory or SaaS applications. If your question is "who signs users in," the answer is Keycloak or another access management product, and midPoint may feed it the identity data.

Can Keycloak handle joiners, movers and leavers without midPoint?

Keycloak can handle a good share of the sign-in side of that lifecycle. It federates users from LDAP or Active Directory, brokers logins to external OpenID Connect or SAML providers, and lets administrators disable accounts and manage roles. What it does not provide on its own is identity governance: request workflows, approval chains, access certification campaigns and reconciliation of entitlements across many target systems. If an auditor asks for periodic reviews of who holds which access and evidence that leavers lost every entitlement, you will need a governance layer or a documented manual process. Confirm which of these controls your compliance framework requires before deciding.

What does the work need from our own staff?

Plan for staff who own the authoritative source of identity (usually HR or the directory), staff who understand each target application's account model, and someone who can operate Keycloak and the midPoint host over time. Keycloak needs a relational database in production (PostgreSQL 14 to 18 among the supported options), and midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported. Your team will also decide who approves access policy, which is a business decision no vendor can make for you. Ask the implementation partner to list these roles in the written scope so ownership is agreed before work starts.

Can our team implement the Keycloak and midPoint integration ourselves?

A team with strong platform skills can, provided it has time to learn both products and test the connectors. Keycloak is Apache-2.0 licensed, so the software itself carries no license fee, and its documentation covers the database, high availability and the Kubernetes Operator in detail. midPoint is EUPL-1.2 or later with no enterprise edition, and Evolveum sells subscriptions for support. The harder part is the design: mapping roles, choosing the authoritative source, setting up ConnId connectors and testing deprovisioning end to end. Many buyers split the work, keeping routine operations in-house and hiring a fixed-scope engagement for the design and first integration.

What drives the cost and effort of this integration?

Cost follows the number of target systems, the quality of your source data, and how much governance you need. Each connector to an application or directory adds mapping and testing work. Rules for roles and approvals take time to agree, because they reflect policy rather than configuration. Ongoing costs include upgrades, since Keycloak plans four minor releases a year and midPoint publishes a release calendar with support windows, for example 4.8 supported until October 17, 2028. Evolveum's Product Support subscriptions come with an 8x5 next-business-day or 24x7 SLA option, and the page lists no prices, so request current pricing directly from Evolveum.

How is a fixed-scope engagement agreed in writing?

DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements are fixed-scope. A useful written scope names the authoritative source, each target system and connector, the roles and approval rules to be implemented, the environments covered and the test evidence you will receive. It should also state what is out of scope, such as audit reports, which independent auditors issue, and ongoing operations, which can be covered by a separate retainer for support, upgrades and continuous testing. DeployOpen does not publish a price list, so the quote follows from the written scope you provide.

Do Keycloak and midPoint need to be licensed together, and does either limit our options?

They do not need a shared license, because each is used independently. Keycloak is Apache-2.0 licensed and midPoint is licensed under EUPL-1.2 or later with Apache 2.0 as a secondary license, and Evolveum states that every line of midPoint code is open source. Neither product forces a paid edition to run the core platform, although support subscriptions are available for both ecosystems. Confirm with Red Hat or Evolveum any support terms you need for production, and check whether your legal team reviews the EUPL obligations for any changes you make to midPoint.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements and supports self-hosted open-source platforms inside your own infrastructure, so the Keycloak and midPoint decision is made against your real directories, applications and governance needs. We scope the design in writing before work starts, then build, document and hand over the result.

How we scope

We map which applications need SSO through Keycloak and which accounts need provisioning from midPoint.
We record the authoritative sources of identity, such as HR records, Active Directory or LDAP, and who owns each.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We deploy Keycloak with a production database, and connect midPoint to target systems through its connector framework.
We set up the provisioning flow so account changes reach Keycloak-connected applications through the directories you choose.
We test login, deprovisioning and role changes end to end, and document the results for your review.

How we hand over

You receive architecture notes, configuration records, runbooks and the reasoning behind each integration point.
We walk your operations and security teams through upgrade paths, including midPoint's release support windows.
We agree which controls and evidence your compliance assessors will need, without issuing any audit opinion ourselves.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can coordinate Keycloak and midPoint upgrades with your change calendar and test environments.
Your midPoint subscription with Evolveum, if you choose one, is contracted separately from DeployOpen's services.

Keycloak vs midPoint