What is Keycloak?
Keycloak is an open-source Identity and Access Management (IAM) server — software that handles user login, session management and authorization, lifting that responsibility off your business applications. Instead of building a login form and password validation separately in every application, a development team delegates these processes to a single, central server.
It helps to state right away what Keycloak is not. It is not an AI model, and it is not a hosted SaaS service. It is standalone infrastructure software — a server you run on your own machines or in a Kubernetes cluster and operate yourself. In that sense it is more akin to a database or an application server than to a finished end-user product.
The mechanics are simple to describe. Keycloak authenticates the user and then issues the application a cryptographically signed token — most often a JSON Web Token?JSON Web Token: a signed JSON-format token carrying identity and permission data (JWT) — carrying information about identity and granted permissions. The application never sees the password and stores no login data. It only receives a verified token it can trust.
The core value it brings is Single Sign-On?Single Sign-On: one login giving access to many applications within a single session (SSO). A user logs in once, and the open session automatically covers every application connected to the same Keycloak server. Logout works globally as well. For an organization running a dozen internal systems, this eliminates password fatigue and centralizes control over security.
Who is behind it?
The project was started in 2013 by Bill Burke and Stian Thorgersen, developers from the JBoss group within Red Hat. The goal was a standards-based SSO solution, initially aimed at applications in the Java ecosystem. The first stable production release appeared in September 2014.
In 2016 Red Hat made Keycloak the upstream project for its commercial Red Hat Single Sign-On (RH-SSO) product. This created a clear arrangement. New features were developed and tested in the open Keycloak community, then packaged, stabilized and sold with commercial support to enterprise customers.
A pivotal moment came in April 2023, when Keycloak was officially accepted by the Cloud Native Computing Foundation (CNCF) as an incubating project?incubating project: the middle of CNCF's three maturity stages (Sandbox, Incubating, Graduated). It means the project is already used in production by multiple organizations and is actively, stably developed, but has not yet reached the top Graduated status reserved for fully mature technologies such as Kubernetes. This was a strategic step to decouple perception of the project from the Red Hat brand and embed it more deeply in the cloud-native ecosystem, alongside Kubernetes and OpenTelemetry. As of 2025 and 2026 Keycloak remains a CNCF incubating project with a very large community, on the order of 34,000 GitHub stars.
How does it work?
The heart of Keycloak is open authentication and authorization protocols. The project deliberately avoids proprietary closed formats — if an application understands industry standards, integration will succeed regardless of programming language.
OAuth 2.0 and OpenID Connect
The foundation is the OAuth 2.0 and OpenID Connect (OIDC) pair. OAuth 2.0 is an authorization framework — it lets an application gain limited access to an API on a user's behalf using an access token. OAuth 2.0 alone, however, does not confirm identity. So Keycloak layers OpenID Connect on top, which verifies who the user is and issues an additional proof of identity in the form of an ID token. These tokens are cryptographically signed and carry so-called claims?claims: assertions about the user carried inside the token, e.g. identifier, email or roles, assertions about the user.
Authorization Code Flow
In a typical web scenario the Authorization Code Flow is used. The application redirects the user to Keycloak, which performs the login and then sends the user back with a code the application exchanges for tokens. For browser and mobile apps, an extra safeguard called PKCE (Proof Key for Code Exchange) protects the code from interception.
SAML 2.0
The second pillar is SAML 2.0 — an older standard based on exchanging signed XML documents called assertions. SAML is considered heavier to integrate but remains critically important for large enterprise systems and legacy software that does not support OIDC. Because Keycloak serves both protocols simultaneously against the same user base, an organization can maintain modern microservices and decades-old systems in parallel while gradually migrating them.
What are its key components?
Keycloak's data model rests on a few fundamental concepts.
Realm
A realm is the top level of isolation. Each realm is a fully separated container with its own users, roles, applications and security policies. A change in one realm does not affect others, which makes it possible to serve many tenants in a multi-tenant model. There is a dedicated Master Realm meant solely for administration — a good practice is not to place ordinary applications inside it.
Clients
Clients are the applications protected by Keycloak. They fall into public clients (browser SPAs and mobile apps that cannot safely store a secret), confidential clients (server-side apps that hold a client secret) and bearer-only clients (APIs that merely verify a presented token).
Roles and groups
Roles and groups implement role-based access control (RBAC). Roles can be defined globally for a realm or locally for a specific application, and composite roles can inherit others. Groups map an organizational structure and simplify bulk permission assignment.
User Federation
User Federation is one of the strongest elements. Keycloak ships connectors for LDAP and Microsoft Active Directory, letting it synchronize and use existing user directories without costly password migration.
Identity Brokering
A related feature is Identity Brokering — Keycloak can delegate login to external identity providers such as Google, GitHub or a corporate Okta server, and the end application need not even know which method the user chose.
What can it be used for?
The most common use is central SSO for a set of applications within one organization — an employee logs in once and gains access to all internal tools. A second popular scenario is securing microservice architectures, where dozens of independent services must verify identity without duplicating login logic.
Keycloak also works well as an identity broker in consumer (B2C) applications, where it exposes social login via Google, Facebook or GitHub accounts. In more advanced scenarios its Authorization Services engine allows building fine-grained access rules beyond simple roles — based on user attributes (ABAC?ABAC: Attribute-Based Access Control — access control based on user and context attributes, e.g. department or time of day, not only on assigned roles), context or the UMA 2.0?UMA 2.0: User-Managed Access — an OAuth 2.0 extension in which the resource owner (the user) decides who may access their resources and on what terms standard.
A built-in authentication flow engine makes it possible to enforce multi-factor authentication (MFA/2FA) using TOTP?TOTP: Time-based One-Time Password — a one-time code derived from a shared secret and the current time, valid for about 30 seconds (e.g. Google Authenticator, FreeOTP) one-time passwords or passwordless login based on WebAuthn?WebAuthn: Web Authentication — a W3C standard for passwordless login using cryptographic keys stored on a device or hardware key and FIDO2?FIDO2: a passwordless authentication standard (FIDO Alliance + WebAuthn) using hardware keys or biometrics; the private key never leaves the device keys. The platform also provides an Account Management console where users manage their own profile, and a theming system that lets you customize login pages in a white-label approach.
Authorization Services — fine-grained authorization
For most applications a role baked into the token (RBAC?RBAC: Role-Based Access Control — access control based on roles assigned to a user. If you have a role, you have the access mapped to it) is enough to let a user in or turn them away. But roles have limits: they are tightly coupled to resources, carry no context, and merely holding a role grants you "some" access. Authorization Services is Keycloak's built-in fine-grained authorization?fine-grained authorization: authorization decided at the level of individual resources and actions based on many conditions (roles, attributes, context), not just coarse roles engine, built on OAuth 2.0 and UMA 2.0. It lets you combine RBAC with attribute-based (ABAC?ABAC: Attribute-Based Access Control — access control based on user and context attributes, e.g. department or time of day, not only on assigned roles), context-based, time-based and rule-based control, and moves the decision out of application code into a central point.
Four authorization points
Keycloak splits authorization into four roles known from the classic policy model:
- PAP (Policy Administration Point) — the admin console and Protection API, where resources and policies are defined.
- PDP (Policy Decision Point) — the central place where the verdict is reached.
- PEP (Policy Enforcement Point) — the enforcer on the application side that asks for and enforces the decision.
- PIP (Policy Information Point) — supplies identity and environment attributes.
The application asks — Keycloak decides.
The model: resource, scope, policy, permission
The starting point is the resource server — a confidential client with authorization enabled. On it rest four fundamental concepts:
- Resource — the protected object: an endpoint, a file, "Alice's account" as a single instance or an entire "bank account" type.
- Scope — the verb, the action on a resource, such as
view,editordelete. - Policy — describes only the condition, reusable and not pointing at the protected object.
- Permission — ties it together with the pattern "X can do Y on resource Z", linking a resource or scope to policies.
Policy types
Keycloak ships built-in policy types covering the most common mechanisms, and missing ones can be added through an SPI.
| Policy type | What the decision is based on |
|---|---|
| Role / User / Group | identity and assignments (RBAC, UBAC) |
| Client / Client scope | the application requesting access |
| Time | an allowed time window |
| Regex / attribute | identity and resource attributes (ABAC) |
| JavaScript | a coded rule (deployed as a JAR for security) |
| Aggregated | a "policy of policies" — combines other policies |
Any policy can be inverted with positive or negative logic, and complex rules can be built by aggregation instead of one giant policy.
How the decision is made: RPT and strategies
The enforcement mode sets the behavior:
- Enforcing (the default) — no policy for a resource means denial.
- Permissive — access is granted when no policy exists.
- Disabled — policy evaluation is turned off.
When several permissions apply to the same resource, the decision strategy resolves the outcome:
- Affirmative — one positive evaluation is enough.
- Unanimous — all must be positive, a single "no" blocks access.
The result of the evaluation is an RPT?RPT: Requesting Party Token — an access token carrying the list of granted permissions, issued by Keycloak after evaluating the policies (RPT) — a token holding the granted permissions, issued by an extension of the token endpoint (the UMA uma-ticket grant). The application can verify it locally or via introspection.
UMA 2.0 and the Protection API
On top sits the Protection API — a UMA-compliant set of endpoints (requiring the uma_protection scope) with which a resource server remotely registers resources and issues permission ticket?permission ticket: an opaque UMA token representing the requested resources and scopes, later exchanged for an RPT (permission tickets). In the UMA flow a client hits a protected resource, receives a permission ticket, sends it back to the authorization server and obtains an RPT. This opens person-to-person resource-sharing scenarios in which the resource owner decides on access.
How does it differ from other approaches?
The main dividing line runs between the self-hosted and SaaS?self-hosted and SaaS: self-hosted means you run and maintain the software on your own infrastructure; SaaS (Software as a Service) is a ready cloud service run by the vendor, billed by subscription, with no servers to maintain models. Auth0 and Okta are commercial cloud services — they require no infrastructure maintenance but bill per monthly active user (per-MAU?per-MAU: billing per Monthly Active User — the cost grows with the number of people who log in), which makes costs grow non-linearly with scale. Keycloak is free to license (Apache 2.0) and gives full control over data, but shifts the cost of maintenance, patching and tuning onto the team.
Among newer open-source competitors, Authentik (written in Python and Go, valued for simplicity and low memory use), Zitadel (lightweight, written in Go, with native multi-tenancy?multi-tenancy: serving many separate customers (tenants) from a single software instance, with full isolation of their data and configuration and a gRPC API?gRPC API: gRPC is Google\u2019s high-performance, binary remote-procedure-call protocol built on HTTP/2 and Protocol Buffers — faster and more compact than classic REST/JSON, strong in B2B SaaS) and Ory (Hydra and Kratos — a headless approach?headless approach: an architecture with no built-in user interface — the system exposes only APIs, and you build the UI layer, e.g. login screens, yourself split into specialized microservices) are worth noting. Against them, Keycloak stands out for its maturity, the strongest and fully certified SAML support, and powerful federation with LDAP and Active Directory. This makes it the default choice for large enterprise deployments, at the price of greater weight and operational complexity.
| Solution | Model | Language / runtime | Distinctive strength |
|---|---|---|---|
| Keycloak | self-hosted (Apache 2.0) | Java (Quarkus) | strongest SAML, LDAP/AD federation |
| Auth0 / Okta | commercial SaaS | closed | no maintenance, per-MAU billing |
| Authentik | open-source | Python and Go | simplicity, low memory use |
| Zitadel | open-source | Go | native multi-tenancy, gRPC API |
| Ory | open-source | Go | headless, specialized microservices |
Keycloak in the AI era
The rise of AI agents and assistants built on large language models has posed a new question for identity systems — how to give an identity to, and control the permissions of, entities that are not human. Keycloak, as a mature OAuth 2.0 and OIDC server, answers this need with several mechanisms that already existed and are now finding new uses.
Identity for machines and agents
The foundation is the service accounts mechanism based on the client credentials flow. An AI agent or service authenticates with its own credentials — without any human involved — and receives a token with its own identity and a narrowed permission scope. This is the basis of machine-to-machine (M2M) communication and the starting point for so-called Non-Human Identities?Non-Human Identities: identities assigned to services, bots and AI agents rather than to people (NHI).
Delegating permissions to an agent
When an agent acts on a user's behalf, handing it the full user token is risky. Standard token exchange (RFC 8693, version V2, fully supported and enabled by default) lets you swap a token for a narrower one — restricted to a specific service (audience) and a smaller set of permissions (downscoping). This way the agent gets exactly as much access as it needs, and nothing more.
Keycloak as an authorization server for MCP
The Model Context Protocol?Model Context Protocol: Anthropic's open standard for connecting AI models and agents to external tools and data (MCP) standard, introduced by Anthropic, defines authorization based on OAuth 2.1. An MCP server acts as an OAuth resource server, while a separate authorization server issues tokens — and Keycloak can take on that second role. The elements the standard requires, such as PKCE?PKCE: Proof Key for Code Exchange — an OAuth 2.0 extension protecting the authorization code from interception; the client proves with a verifier–challenge pair that it started the login, authorization server metadata (RFC 8414) and dynamic client registration (RFC 7591), are among Keycloak's native capabilities.
resource parameter in token exchange. Before a production deployment it is therefore worth verifying the current state of support, especially against the confused deputy attack that the MCP specification warns about.Key limitations and challenges
The biggest challenge is operational cost. Despite the free license, total cost of ownership (TCO) includes infrastructure, dedicated DevOps staff and regular updates. Multi-node scaling relies on the distributed Infinispan cache and the JGroups clustering protocol, and correctly maintaining cluster state in a high-availability setup is among the harder operational tasks.
A system of this scale is also an attractive attack target. Over the period studied, significant vulnerabilities surfaced, such as CVE-2024-4540, in which the server mistakenly wrote sensitive PAR parameters in plain text into a cookie accessible to the client. Incidents like these enforce discipline in patching. On the other hand, the project also deprecated its older integration libraries (the so-called Java adapters), judging native OIDC and OAuth 2.0 support in frameworks like Spring Security to be sufficient. For teams maintaining older integrations, that means migration work.
Why does it matter?
Keycloak is a good example of the maturity of the open-source model in an area where the stakes are exceptionally high — identity security. Identity has become the new security perimeter. In a world of microservices, cloud and remote work, it is not the firewall but the correctly verified token that decides who has access to what. Keycloak lets you build that layer once, centrally and according to open standards, instead of scattering fragile security logic across dozens of applications.
Its importance grows especially where data sovereignty is a requirement rather than a preference — in finance, public administration and regulated-market institutions. The ability to keep the entire identity database on your own infrastructure, without trusting a foreign cloud provider, is hard to overstate. The project's move to the CNCF and its shift to the lightweight Quarkus runtime show this is not a museum piece but an actively modernized technology. For anyone building systems that require login, Keycloak is a reference point worth understanding, even if a SaaS solution is ultimately chosen.
Keycloak is neither lightweight nor maintenance-free, but it remains one of the most solid identity foundations in the cloud-native ecosystem. Its strength lies in the combination of openness, standards compliance and maturity, which together make it the default choice for serious on-premise deployments.