What is Keycloak? Open-Source Identity & Access Management Explained (2026)

Hardly any infrastructure decision in 2026 carries more hidden weight than the identity question: who manages the logins, roles and sessions of your customers and employees — and at what price? SaaS identity services bill per active user, which can become the most expensive line of the cloud bill as portals grow. And they manage the most sensitive data asset there is: identities. Keycloak is the open-source answer to both.

About the term itself: identity and access management bundles two tasks that get mixed up in everyday conversation. Authentication answers who someone is — via login, MFA or passkey. Authorization answers what that person may do: roles, permissions, groups. Keycloak handles both centrally; your applications simply ask, instead of maintaining their own login logic.

This overview answers the questions that actually come up in decision-maker meetings: Which products does Keycloak replace? How current and future-proof is the project? Which four concepts do you need to know to evaluate a proposal? And when is Keycloak simply the wrong choice? All researched figures are current as of September 2026 and documented at the end of the article.

Keycloak takes over the identity layer: login and SSO across all applications, user and role management, MFA, self-service (password reset, profile) and the federation of existing directories. Depending on your starting point, it substitutes very different systems:

To be clear about the boundary: Keycloak replaces neither a CRM nor your application's user data model — it is the authentication and authorization layer in front of them. In our projects it often works alongside Supabase: Supabase Auth for lean single apps, Keycloak as soon as SSO across several applications, directory integration or fine-grained roles come into play.

The pattern behind the table: Keycloak replaces less a set of features than a business model. All the services listed monetize per user or per login; Keycloak decouples the identity layer from that pricing logic. In our project experience, the switch therefore rarely pays off at 500 users — but almost always once the user count reaches five digits and every pricing tier becomes a negotiation about your growth.

No per-user license costs: whether 1,000 or 500,000 users — the software costs stay at zero. With SaaS IdPs, the MAU bill is the biggest hidden scaling cost block.

Data sovereignty over the most sensitive asset: identities, credentials and sessions live on your EU infrastructure — no third-country transfers, short data processing chains, full audit control.

Full protocol and legacy coverage: OIDC, OAuth2 and SAML for modern and legacy systems alike, LDAP/Active Directory federation for existing directories.

Customizable authentication flows: registration, step-up MFA, customer-specific login journeys and your own extensions (SPIs) — without waiting for a vendor's feature roadmap.

Exit security and governance: the service keeps running no matter what a vendor does with prices or products — and as a CNCF project with Red Hat origins, Keycloak is unusually broadly secured on top of that.

White-labeling included: login screens run under your brand and domain — no "Powered by" third-party branding at the most sensitive moment of the user relationship.

The takeaway for your board memo: open-source IAM trades ongoing license costs for one-off project costs and predictable operations. Whether that trade pays off is not a matter of belief but a calculation with your user count.

As of September 28, 2026, Keycloak 26.7.4 is the current version, released on September 16, 2026. More important than the number is the cadence behind it: with version 26.0 in October 2024, the project deliberately slowed its pace — away from four major releases per year, toward four minor releases annually and one major release every two to three years.

For your planning this means: upgrades have become predictable. Since 26.0, breaking changes arrive only as opt-in — a feature is marked as deprecated in a minor release and removed only in the next major release. The days when every quarter brought a version jump with migration effort are over. For budget planning, one larger upgrade window per year is usually enough.

Predictable does not mean optional, though: between August 5 and September 16, 2026 alone, four patch releases appeared (26.7.1 to 26.7.4). Identity systems sit at the top of every attacker's list, so patches are a duty, not a nice-to-have. How to organize updates without maintenance-window drama is covered in our guide Keycloak major upgrades in practice.

A practical tip for vendor conversations: do not ask a provider whether they know Keycloak, but which version they are running right now and what their patch process looks like. Answers well below the 26 line point to postponed upgrades — and with them, open security holes. The same question works for every open-source building block in your stack, by the way.

Keycloak originated at Red Hat and has been an incubating project of the Cloud Native Computing Foundation (CNCF) since April 10, 2023 — the same foundation that carries Kubernetes. Incubating is the middle of three maturity levels: production use by several organizations and an active contributor base are proven, graduated status is still ahead.

For your risk assessment, the construction behind it is what counts: the CNCF decouples the project's future from the interests of a single vendor. Red Hat stays on board with the commercial Red Hat Build of Keycloak but no longer decides alone — a rare case of double insurance for open-source infrastructure.

Keycloak organizes identities in realms (separate tenants, e.g. customers vs. employees); applications connect as clients via OIDC or SAML. Existing user bases come in through user federation (LDAP, Active Directory), external identities through identity brokering (e.g. "Login with Google" or a partner IdP).

So much for the 90-second version. These four terms show up in every Keycloak proposal and every architecture review — so here is what they mean for your decision.

A realm is a fully isolated administrative area: its own users, its own roles, its own login look, its own security rules. The typical mid-market pattern is two realms — one for employees with AD integration, one for customers with self-service registration. Relevant for you because a single Keycloak instance serves several user worlds separately: the new customer portal needs no second identity infrastructure. Acquisitions benefit too: an acquired company docks on as another realm.

Every application that gets its login from Keycloak is a client: the customer portal, the internal dashboard, the mobile app, even the ERP with its SAML interface. For project calculation this is the most important variable: the effort of a Keycloak rollout grows less with the user count than with the number of clients and their legacy baggage. Ten clean OIDC apps connect faster than three legacy systems.

Brokering means: Keycloak accepts identities from other providers and translates them for your applications. That starts with "Login with Google" and ends with the B2B case that decides customer portal deals: your enterprise customer wants their employees to sign in to your portal with their corporate login (Entra ID, Okta). With brokering, this enterprise SSO is configuration work instead of a development project — without it, the same requirement would mean custom development per customer.

Federation solves the reverse problem: your users already exist, typically in an Active Directory or LDAP directory. Keycloak connects the directory instead of replacing it — IT keeps its familiar user management, the applications get modern SSO on top. In modernization projects this is often the decisive argument, because nobody wants to touch the Active Directory on day one.

MFA, passkeys/WebAuthn and session management are core features; login themes and server extensions (SPIs) make flows and appearance customizable. Technically, Keycloak runs as a container on the Quarkus runtime — from a single instance to a highly available cluster.

Passkeys in particular are more than a checkbox on the feature list in 2026: they replace passwords with phishing-resistant sign-in. What that means for your customer portal in practice is covered in Keycloak, passkeys and MFA.

With these four terms you can sanity-check any Keycloak proposal in five minutes: how many realms are planned, how many clients will be connected, which directories are federated, which external IdPs are brokered? The project scope follows from those four answers — not from the user count.

First, the definitions: single sign-on (SSO) is the goal — sign in once, use all applications. OIDC and SAML are the two protocols that implement this goal technically, and Keycloak is the instance in the middle that speaks both. Anyone selling you SSO without asking about the protocols in your system landscape has not looked at it.

OpenID Connect (OIDC) is the modern standard: lean, built for web and mobile applications, first choice for everything new. SAML is the enterprise veteran from the 2000s: XML-based, heavier, but hard-wired into ERP systems, HR software and older line-of-business applications. A realistic mid-market landscape needs both at the same time — and exactly this dual role separates Keycloak from leaner auth services that only speak OIDC.

The rule of thumb for decision-makers: OIDC for everything new, SAML wherever the other side cannot do anything else. A legacy system that only speaks SAML is not a deal-breaker but configuration effort. Which questions to ask before you commit is covered in our decision guide SAML vs. OIDC explained.

Honesty stays honesty: a managed IdP is the right path when no team can own operations — identity is critical infrastructure, and updates and availability are a duty, not a nice-to-have. For a single lean app, Supabase Auth is often enough. Keycloak plays to its strengths when SSO connects several applications, directories need federating, B2B portals need fine-grained roles, compliance demands data sovereignty, or the SaaS IdP's MAU bill becomes a strategic burden.

The lower bound in concrete terms: a single Next.js app with email login and two roles does not justify its own identity server. For that we use Supabase Auth — already included in the database stack, with no extra operational overhead. The switching point comes with the second application, the first enterprise customer with an SSO requirement or the first directory integration. Our market overview Keycloak alternatives compares the options before and in between.

Honesty also includes this: managed services deliver side benefits Keycloak does not bring — anomaly detection in login traffic, for example, or the operator's compliance certificates. If you need exactly these features and accept the US data flow, Auth0 and friends serve you well. The comparison is worth making in both directions.

The most common Keycloak case in our projects is the B2B customer portal: business customers with their own identities, fine-grained roles, SSO into existing systems. Building such portals, from the first architecture sketch to SSO and ERP integration, is the pattern most of our Keycloak work follows.

The short formula for your steering committee: Keycloak pays off as soon as identity has to be more than a login form — when it connects several portals, mirrors existing directories and makes the SSO requirements of enterprise customers achievable.

With identity, operations are no side note: if login fails, every connected application stands still. Availability, backups, patches and monitoring must be settled before the first user migrates. We run Keycloak on EU infrastructure, typically Hetzner in Germany: identity data stays physically and legally in Europe. From a single container to a highly available cluster, Keycloak self-hosting explained compares the options.

For your GDPR assessment this means: no third-country transfer of your most sensitive data set, a short data processing chain, audit logs under your control. In our experience, this argument convinces data protection officers faster than any standard contractual clause from a US provider. If a hosting provider enters the picture, examine its location and subprocessors just as strictly.

Open source shifts costs from licenses to project and operations: in our project classification, a Keycloak setup including integration ranges from a focused MVP (€8,000–20,000) to a full portal integration (€20,000–60,000); operations on EU infrastructure sit in the three-figure euro range per month. We have run those numbers openly for the Supabase-plus-Keycloak stack we recommend to clients.

The full calculation, including the items that vendor comparisons like to leave out (updates, monitoring, person-days for operations), is broken down in What does Keycloak cost?.

How we combine Keycloak with Supabase and Next.js into B2B web apps is shown on our Supabase development service page — embedded in our overall approach of AI-assisted software development.

If you are facing the identity decision, I recommend three steps. First, take inventory: which applications, which user groups, which directories are involved? Second, run the honest cost calculation of your current or planned SaaS IdP over three years, with realistic user growth. Third, settle the operations question: who owns updates, availability and monitoring — your team or a partner?

You can handle the first two steps internally. For the third, book a no-obligation consultation call — you will leave with a clear recommendation, even if it is "no Keycloak". And if you want to go deeper first: the articles linked here on cost, hosting, alternatives and protocols together form the complete decision path.