---
title: "Is Keycloak Free? Keycloak vs authentik and What Each Really Costs"
description: "Keycloak is Apache 2.0 with no paid tier. authentik is open core — MIT plus a proprietary enterprise directory. That licensing difference matters more than any feature table, and SCIM coverage is not equal either."
author: Aleksei Aleinikov
date: 2026-08-13
lang: en
tags: [is keycloak free, keycloak vs authentik, keycloak scim, open source sso, identity provider]
canonical: https://www.alekseialeinikov.com/en/blog/topics/security/is-keycloak-free-keycloak-vs-authentik-2026
source: alekseialeinikov.com
---

# Is Keycloak Free? Keycloak vs authentik and What Each Really Costs

"Is Keycloak free?" is the most searched question about it, and the answer is genuinely yes — Apache 2.0, no paid tier, no seat count, nothing held back.

That answer is also useless on its own, because free software is not free infrastructure. And because the more interesting question is what *kind* of free you are getting, which is where Keycloak and authentik differ in a way no feature table shows.

![Keycloak ships one Apache 2.0 licence; authentik splits its repository between MIT code and a proprietary enterprise directory.](https://www.alekseialeinikov.com/blog/keycloak-authentik-2026.webp)

## Yes, Keycloak Is Free — Here's the Precise Version

Keycloak is Apache 2.0. There is no Keycloak Enterprise with extra features, no per-user licence, no feature flag that unlocks when you pay. The project is a **CNCF incubating project**, accepted in April 2023, with its first commit back in July 2013.

Everything is in the box:

- SSO with single logout across applications
- **OpenID Connect, OAuth 2.0 and SAML 2.0**
- Identity brokering against other OIDC or SAML providers, plus social login
- User federation against **LDAP and Active Directory**
- MFA: OTP, WebAuthn and passkeys, recovery codes
- Fine-grained authorization services beyond simple roles
- Admin console, self-service account console, themes, clustering

Red Hat sells a supported build with an SLA. That is a support contract, not a different binary with more features.

**authentik works differently.** Its repository is explicit about being split:

```text
LICENSE (root)
├── most code                → MIT
├── website/                 → CC BY-SA 4.0
├── client-side JavaScript   → MIT Expat
└── authentik/enterprise/    → proprietary EE licence
```

The enterprise licence text is not ambiguous. The software there *"may only be used in production, if you… have a valid authentik Enterprise Edition subscription for the correct number of user seats"*, and while you may modify it for development and testing, it is *"forbidden to copy, merge, publish, distribute, sublicense, and/or sell"*.

This is **open core**, and it is a legitimate model — it is how the company funds the work. But it is a different proposition from Apache 2.0, and it deserves to be understood before adoption rather than during a licence review.

authentik's paid tiers are public: **$5 per internal user per month** billed annually, $0.02 per external user, with service accounts free. Enterprise Plus starts at **$20,000 a year**.

## What Actually Sits Behind authentik's Paywall

The free tier is not a crippled demo. It includes OIDC, SAML, LDAP, **SCIM**, RADIUS, Kerberos and the proxy provider, is OpenID Certified, covers B2B and B2C, and even includes browser-based RDP and SSH access. What it does not include is support.

The enterprise tier is mostly integrations and compliance:

| Enterprise-only | Why it matters |
|---|---|
| Google Workspace and Microsoft Entra ID provisioning | Outbound sync to the two biggest directories |
| Shared Signals Framework (Apple Business Manager) | Cross-vendor security event sharing |
| Client certificate authentication (mTLS) | Common in regulated environments |
| OAuth 2.0 authentication for SCIM | Bearer-token SCIM stays free |
| RADIUS EAP-TLS | Certificate-based network auth |
| Enhanced audit logging, password history checks | Compliance evidence |
| FIPS compliance (Enterprise Plus) | FedRAMP work |

Read that list honestly: for a self-hosted internal SSO with a handful of applications, none of it is required. For an organisation syncing into Entra ID with mTLS and audit requirements, most of it is.

## The Part That Surprised Me: Licence Enforcement Is in the Code

authentik does not merely ask you to comply. The enforcement is implemented, and you can read the thresholds:

```python
THRESHOLD_WARNING_ADMIN_WEEKS = 2
THRESHOLD_WARNING_USER_WEEKS = 4
THRESHOLD_WARNING_EXPIRY_WEEKS = 2
THRESHOLD_READ_ONLY_WEEKS = 6
```

Exceed your seat count or let the licence lapse, and the instance walks down a staircase: administrators get warned after two weeks, end users after four, and after **six weeks the instance goes read-only**. In that state middleware rejects write operations against the API.

It is a deliberately soft failure — logins still work, the flow executor still runs, and licence management stays writable so you can fix it. Nobody gets locked out of their applications. But your identity provider stops accepting changes, which during an incident is its own kind of bad day.

Licences are JWTs validated against a bundled certificate, carrying separate internal and external user counts, and usage is recorded on a schedule.

None of this is hidden or dishonest — it is in a public repository. But "open source" and "runs unmodified in production forever" are not the same sentence, and that distinction is exactly what someone typing *is keycloak free* is trying to establish.

![authentik licence states escalate from warnings to a read-only instance after six weeks.](https://www.alekseialeinikov.com/blog/keycloak-authentik-license-2026.webp)

## SCIM: Both Have It, But Not Symmetrically

This is where the comparison stops being balanced, and it is the detail that actually decides projects.

SCIM has two directions, and they are different problems:

- **Inbound** — an HR platform or identity governance tool provisions users *into* your IdP
- **Outbound** — your IdP pushes accounts *out* into Slack, GitHub, and everything else

**Keycloak covers the inbound half.** Its SCIM API makes Keycloak a SCIM server. It landed in **26.7 as a preview feature**:

```bash
# 1. enable the feature on the server
bin/kc.sh start --features=scim-api

# 2. then enable it per realm:
#    Realm settings → General → SCIM API → On

# base URL
https://<host>/realms/<realm>/scim/v2
```

Endpoints are `/Users`, `/Groups`, `/Schemas`, `/ResourceTypes` and `/ServiceProviderConfig`, with full CRUD and PATCH, SCIM filter syntax, pagination, and the Enterprise User extension plus custom extensions mapped from user profile attributes. Access requires a bearer token with the right audience, and **public clients are rejected outright**.

Worth knowing about "preview" in Keycloak, because the word means something specific there — it is *supported for production use-cases, but does not guarantee seamless upgrades*, must be feature complete, and requires a security review before reaching that stage. That is a stronger promise than "beta" in most projects, and weaker than "stable" in all of them. Current limits are visible in the service provider config: sorting, ETags and password change are not supported yet.

**authentik covers both halves**, and both sit outside the proprietary directory:

- `providers/scim` — pushes users and groups outward into applications
- `sources/scim` — accepts inbound provisioning, so authentik can be a SCIM server too

| | Keycloak 26.7 | authentik |
|---|---|---|
| Inbound (being the SCIM server) | yes, preview, off by default | yes |
| Outbound (provisioning into apps) | **no** — listed as planned | yes |
| Licence tier | Apache 2.0 | open source tier |
| Caveat | double enable, no sort/ETag yet | OAuth auth for SCIM is enterprise |

I originally assumed these two worked in opposite directions. They do not — **authentik covers both, Keycloak currently covers one**, and that one is still a preview. If outbound provisioning into SaaS applications is your requirement, this is the clearest functional gap in the whole comparison.

Keycloak's docs list federation *from* external SCIM providers and push-based updates as planned, so the gap may close. It is open today.

![SCIM has two directions: authentik covers both, Keycloak currently covers only inbound.](https://www.alekseialeinikov.com/blog/keycloak-authentik-scim-2026.webp)

## Where the Money Actually Goes

Neither licence is the expensive part. Self-hosted identity costs what any stateful, tier-zero service costs.

**It is tier zero.** When your IdP is down, nobody logs into anything — not the wiki, not the dashboards, not the incident tooling you need to fix the IdP. That reality dictates the architecture: a properly managed database, backups you have actually restored, multi-instance deployment, and a tested upgrade path.

**Upgrades are real work.** Keycloak's cadence is brisk, and features move between preview and supported between releases. authentik ships frequently too. Either way you are on a treadmill, and falling behind on an identity system is a security problem rather than a maintenance one.

**Someone has to own it.** The unglamorous truth: the recurring cost of free SSO is an engineer's attention. If a $5-per-user licence buys support that saves a day a month, the arithmetic can favour paying — that is a calculation, not a betrayal of principles.

![Where effort actually goes on a self-hosted identity provider: the licence is the smallest slice.](https://www.alekseialeinikov.com/blog/keycloak-authentik-cost-2026.webp)

The same reasoning runs through [killing service account keys with Workload Identity Federation](https://www.alekseialeinikov.com/en/blog/topics/security/kill-service-account-keys-workload-identity-federation-2026): the cheapest control is the one nobody has to remember to operate.

## How I'd Choose

**Choose Keycloak when:**
- You want one licence with no commercial tier and no seat maths
- SAML matters, because enterprise integration still runs on it
- You need LDAP or Active Directory federation as a core capability
- You want external systems to provision *into* your IdP (with the 26.7 preview caveat)
- Fine-grained authorization services would otherwise be a separate component

**Choose authentik when:**
- You need to push provisioning *out* to SaaS applications — today this is the clearest functional gap in Keycloak
- Its flow-based customisation matches how you think about authentication
- The enterprise features are either unnecessary or clearly worth per-user pricing
- A modern admin UI is a real productivity factor for your team

**Choose a hosted IdP when** nobody on the team wants to own a tier-zero stateful service — which is a legitimate answer, and cheaper than pretending otherwise.

## What Good Looks Like

- One identity provider, not three, and everyone knows which one is authoritative
- The database is backed up, and the restore has been rehearsed
- Upgrades happen on a schedule, not when something breaks
- MFA is enforced by policy, not requested by email
- Whoever picked the tool has read the licence, not just the feature page
- Tokens live in cookies with the right flags rather than in `localStorage`, which is the [other half of getting auth right](https://www.alekseialeinikov.com/en/blog/topics/security/stop-storing-jwts-in-localstorage-cookie-auth-for-spas-2026)

## The Bottom Line

Keycloak is free in the strongest sense: Apache 2.0, every feature, no seats to count. authentik is free in the common modern sense: a genuinely capable MIT core, with a proprietary directory in the same repository that you may not run in production without a subscription.

Both are good software. The licensing difference is not a scandal — it is a fork in the road, and it belongs at the start of the evaluation rather than the end.

On SCIM, check the direction before you check the box. Both advertise support, but authentik covers inbound and outbound while Keycloak covers only inbound, and only as a preview.

The principle is the same one behind [choosing a policy engine](https://www.alekseialeinikov.com/en/blog/topics/security/opa-vs-kyverno-2026-kubernetes-policy-engine): name the capability you need before you name the tool.
