Before we can explain why it’s open source, let’s establish exactly what Keycloak does.

Keycloak is a piece of software that handles Identity and Access Management (IAM) for other applications. In plain terms, it is the component that answers “who are you?” and “what are you allowed to do?” so that individual apps don’t each have to build their own login system, password storage, and permission logic from scratch.

Keycloak began life inside Red Hat, a well-known open-source software company, and has since become one of the most widely adopted identity platforms in the world — used everywhere from small startups to large banks and government agencies. What makes it especially notable is not just what it does, but how it is distributed: entirely as open source, free for anyone to download, inspect, modify, and run.

The phrase gets used loosely — let’s define it precisely before applying it to Keycloak.

Open source means the underlying source code of a piece of software is publicly available, and a license grants everyone the legal right to view it, run it, modify it, and often redistribute their modified version. This is the opposite of proprietary (or “closed source”) software, where the company keeps the code secret and only sells you the finished, unmodifiable product.

Keycloak is released under the Apache License 2.0, one of the most permissive and business-friendly open-source licenses that exist. It allows anyone — including competing companies — to use, modify, and even sell products built on top of Keycloak, as long as they keep the required copyright notices intact. There is no requirement to pay Red Hat, ask permission, or share your own modifications back.

Understanding the origin story explains a lot about why the open-source decision was made.

Keycloak was created inside Red Hat, a company whose entire business, since its founding, has been built around open-source software — most famously Red Hat Enterprise Linux, a commercially supported version of the open-source Linux operating system. Red Hat needed a modern, standards-based identity and access management solution for its own growing ecosystem of products, and rather than building something proprietary, it built Keycloak in the same open manner as the rest of its portfolio.

A quick look at what’s actually inside the box that got open-sourced.

Every one of these components is fully visible in the public source code. This matters directly for the open-source discussion: security researchers, government agencies, and paranoid engineers everywhere can inspect exactly how tokens are generated, how passwords are hashed, and how permissions are checked — instead of trusting a vendor’s word for it.

Being “open source” doesn’t mean chaos — there’s a real structure behind how changes get accepted.

Keycloak’s development happens in the open, on a public repository, where anyone can propose a change. But not every proposal gets accepted automatically — there is a review process, maintained by a mix of Red Hat employees and trusted community members, who evaluate whether a change is safe, well-tested, and aligned with the project’s direction.

flowchart LR
    A[Contributor Proposes Change] --> B[Automated Tests Run]
    B --> C[Maintainers Review Code]
    C -->|Approved| D[Merged into Main Codebase]
    C -->|Changes Requested| A
    D --> E[Included in Next Public Release]
    E --> F[Anyone Can Download and Use It]
        

Keycloak also participates in the Cloud Native Computing Foundation (CNCF) ecosystem as a sandbox project, which adds an extra layer of neutral, vendor-independent oversight — a signal that the project isn’t meant to be permanently locked to one company’s private control, even though Red Hat remains its largest contributor.

Understanding the mechanics helps explain why openness here builds trust rather than risk.

When a user logs into an application protected by Keycloak, the flow generally follows the open OpenID Connect standard — the same publicly documented standard used across the industry, not a secret Keycloak-only mechanism.

sequenceDiagram
    participant U as User
    participant App as Application
    participant KC as Keycloak
    U->>App: Try to access the app
    App->>KC: Redirect user to Keycloak login
    U->>KC: Enter credentials
    KC-->>U: Redirect back with authorization code
    U->>App: Present authorization code
    App->>KC: Exchange code for tokens
    KC-->>App: Return signed access/ID tokens
    App-->>U: Access granted
        

Because this entire flow follows a public, well-audited standard, and the implementation code is itself public, anyone can verify that Keycloak isn’t doing anything sneaky — no hidden backdoors, no undisclosed data collection, no shortcuts around security. This transparency is a direct product of the open-source decision, not a side effect.

This is the heart of the question — how does a company make money from something it gives away for free?

This might sound contradictory at first: why would a company spend years of engineering effort building something and then hand it out for free? The answer lies in a well-established open-source business strategy sometimes called “open core” or the “services and support” model.

Like any strategic decision, going open source is a genuine trade-off, not a pure win.

Since Keycloak’s entire job is security, its openness deserves a closer look.

A common instinct is to assume that keeping code secret makes it more secure — if attackers can’t see the code, they can’t find flaws. In security circles, this idea is called “security through obscurity,” and it’s widely considered a weak and unreliable strategy on its own.

In practice, Keycloak’s security strength comes from following proven, standardized protocols correctly, applying least-privilege defaults out of the box, and benefiting from a large, motivated community actively looking for and reporting weaknesses — not from hiding how it works.

A healthy open-source project can be measured, just like a healthy production system.

Organizations evaluating whether to depend on an open-source project like Keycloak typically look at a set of health signals before adopting it — essentially “monitoring” the project itself, not just the software it produces.

Being open source doesn’t automatically mean it’s adopted wisely — how a team uses it still matters.

A practical checklist for teams considering or already running Keycloak.

Keycloak’s open-source model isn’t unique — it sits within a well-established tradition.

Across all of these examples, the pattern repeats: the free, open code drives adoption and trust, while paid services around it — support, certification, hosting, consulting — are where the sustaining revenue comes from.

Yes. The Apache 2.0 license permits anyone to run the community edition in production at no cost. Paid options exist only for organizations that want official vendor support, certified builds, or additional enterprise features.

Primarily Red Hat, whose employees make up a large share of the core maintainers, alongside volunteer and other-company contributors. Red Hat funds this work because it drives adoption of its broader paid enterprise offerings.

Yes, the Apache 2.0 license explicitly allows this. This is a deliberate trade-off — it maximizes adoption and community trust, even though it means competitors can build commercial offerings on the same code.

Not automatically — but transparency removes the need to simply trust a vendor’s claims, and a large, active community reviewing the code tends to catch and fix issues faster than secrecy alone would.

The underlying code is largely the same open-source project. The paid offering mainly adds official support contracts, guaranteed patch timelines, certified builds, and professional services — not a fundamentally different product.

Yes, the license permits modification. Best practice is to use Keycloak’s supported extension points where possible, rather than editing the core code directly, to keep future upgrades manageable.

Keycloak is open source not because giving away valuable software is a charitable accident, but because it’s a deliberate, well-proven strategy. Releasing the code publicly under the permissive Apache 2.0 license drives faster adoption, builds deep trust through transparency, and taps into a global community of contributors and security researchers who improve the project for free. Red Hat, the company behind most of its development, doesn’t monetize the code itself — it monetizes the support, certification, and services built around it, the same open-core model that made Red Hat’s Linux business successful long before Keycloak existed. The result is an identity and access management system that organizations of any size can inspect, trust, run for free, and eventually pay for professional support on, only if and when they need it.