Keycloak: product and architecture
This Keycloak review covers the open-source identity and access management server that most teams reach for when they decide not to rent authentication by the user. Keycloak issues and validates tokens over OpenID Connect and OAuth 2.0, speaks SAML for the enterprise applications that still need it, federates users from LDAP and Active Directory, and brokers logins to social and enterprise identity providers. It is a CNCF project under the Apache-2.0 licence, run on your own infrastructure. We evaluated it against its official documentation, its licence and governance, and its GitHub repository, which carried 36,867 stars when we checked on 19 September 2026.
Overview
Keycloak exists to remove authentication from application code. Rather than each service implementing login, password reset, multi-factor prompts and session handling, they delegate to Keycloak and accept a token. That is the same proposition a hosted identity service makes; the difference is where it runs and how it is paid for.
The project began at Red Hat and is now a CNCF project, which matters for the buying decision in a specific way: there is no vendor with a per-user meter, and no commercial relationship to renegotiate as your user count grows. The cost is infrastructure and the people who operate it.
Keycloak organises tenancy through realms. A realm holds its own users, roles, clients and identity providers, which makes it practical to separate staff identity from customer identity inside one deployment without them seeing each other.
Key Features and Architecture
The protocol surface is the reason to choose it. Keycloak implements OpenID Connect and OAuth 2.0 for modern applications and SAML 2.0 for the estate that predates them, which means one server can sit in front of a React front end and a decade-old Java application at the same time.
User federation connects Keycloak to existing directories. It reads users from LDAP and Active Directory rather than requiring a migration, so an organisation whose staff identity already lives in AD can put Keycloak in front without moving anyone. Identity brokering covers the other direction: delegating login to an external provider, whether that is a social account or another organisation's SAML identity provider in a B2B arrangement.
Authorization services go past authentication. Keycloak can hold fine-grained permission policies — resources, scopes and policies evaluated centrally — for teams that want authorisation decisions out of application code as well.
The admin console is a full web interface over all of it: realms, clients, roles, federation, flows. Authentication flows are configurable, which is how multi-factor requirements, step-up authentication and custom steps get expressed without code.
Client integration is through standard protocol libraries rather than a proprietary SDK. The project publishes keycloak-js for browser applications; everything else can use any conformant OIDC or SAML client, which matters on exit as much as on entry — an estate that speaks standard protocols can be moved to another conformant server without rewriting every application against a new vendor's API.
Ideal Use Cases
Keycloak fits an organisation with the operational capacity to run a stateful, security-critical service and a reason to avoid per-user billing. That is most often a team with a large user count, where a monthly-active-user meter becomes the dominant line item.
It fits estates with mixed protocol requirements. If some applications need SAML and others OIDC, one Keycloak deployment covers both.
It fits data-residency and air-gapped requirements absolutely. Where user identity cannot leave your infrastructure or your jurisdiction, a hosted identity service is not a candidate and Keycloak is the obvious answer.
It fits teams that already run Kubernetes and Java services, where operating another JVM workload is routine rather than novel.
Do not use Keycloak if nobody on the team wants to own an authentication server. It is the front door to every application you have: upgrades, database backups, certificate rotation and availability are now yours. A small team without that capacity will get better security outcomes from a hosted service, even paying per user.
Pricing and Licensing
Keycloak is free under the Apache-2.0 licence, with no paid tier, no per-seat charge and no per-active-user meter. It is a CNCF project rather than a vendor product, so there is no commercial edition to be upsold to and no licence negotiation.
That does not make it free to operate. The real cost is a database, the compute to run the server, high availability if authentication must not go down — and it must not, because every application depends on it — plus the engineering time for upgrades and incident response. Keycloak releases frequently, and staying current is part of the commitment.
The comparison that matters is against per-monthly-active-user pricing. A hosted identity service such as Auth0 carries a free allowance and then bills by external monthly active users across named tiers, with enterprise terms quoted; its own pricing page is the place to read the current rates. The shape is what matters here: those costs scale with your success, and Keycloak's do not. We recommend modelling your own user growth against both shapes before deciding, because the crossover sits at a volume specific to your business rather than at any general threshold, and it moves with how many of your users are external customers rather than staff.
Strengths & Trade-offs
Pros
- No per-user cost, ever. Apache-2.0 with no commercial edition means user growth does not change the bill.
- OIDC, OAuth 2.0 and SAML in one server. A mixed estate does not need two identity products.
- Federates instead of migrating. LDAP and Active Directory users stay where they are.
- Realms give real separation. Staff and customer identity can live in one deployment without sharing a namespace.
- Authorization services included. Fine-grained policy evaluation is available without a second product.
Cons
- You are operating an authentication server. Availability, upgrades, backups and incident response all become yours, for a service every application depends on.
- Configuration surface is large. Realms, clients, flows, mappers and federation providers reward expertise and punish guesswork.
- JVM operational profile. Memory and tuning characteristics are a Java service's, which is unremarkable in a Java estate and a new skill in one that is not.