Keycloak and its alternatives: revisit your identity provider before you standardise SSO

Manoj Shukla
October 7, 2026

A SaaS company in Hyderabad runs Keycloak 24 on two virtual machines. It was set up in 2024 for about 60 internal tools and has worked quietly since. Now, in one month, enterprise customers want to log in with their own Entra ID or Okta, HR wants leavers removed from every tool the same day (SCIM), and one developer says authentik would be easier while the platform lead likes Zitadel’s tenant model. Nobody has upgraded Keycloak in a year, and security asks whether that version still gets patches.

These are the right questions to ask before you standardise single sign-on, because the identity provider becomes the front door to everything. This post compares Keycloak with the main open-source alternatives on history, licences, protocols, storage, tenancy, upgrades and security record. Facts come from the projects’ repositories, release pages, licence files, official docs, CVE records and vendor pages, checked on 7 October 2026. The drill results are from my own local run. The identity provider usually ends up guarding your secrets manager too, so the earlier post on Vault and OpenBao is a useful companion.

The short version

Keycloak 26.8.0 shipped on 1 October 2026. It is Apache 2.0, a CNCF incubating project since April 2023, and the base of the Red Hat build of Keycloak. Minor releases now come every quarter.
Keycloak 26.8 made the SCIM API and multi-cluster v2 supported. It remains the most complete option for OIDC, SAML, LDAP and multi-tenant setups.
authentik is MIT at its core but has an enterprise directory under a separate commercial licence. Zitadel moved from Apache 2.0 to AGPL 3.0 with v3 in 2025. Read the licence files, not the badges.
Authelia, Ory, Kanidm and Dex are not drop-in Keycloak replacements. They are a forward-auth portal, a headless toolkit, an identity server for Linux and infrastructure, and an OIDC broker.
SAML XML handling is a repeated source of serious bugs across these projects, so patch speed matters more than feature lists.
In my drill, Keycloak in dev mode used about 562 MiB of memory after start. Ory Hydra used about 57 MiB and was ready in about 0.2 seconds, but it has no login screen at all.

Where things stand on 7 October 2026

Project

Latest release (IST)

Licence

Storage it needs

Backing

Keycloak

26.8.0, 1 October 2026

Apache 2.0

Relational database (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and others) plus embedded Infinispan caches

CNCF incubating; Red Hat

authentik

2026.8.3, 18 September 2026

MIT core, separate EE licence for authentik/enterprise/

PostgreSQL only since 2025.10

Authentik Security

Zitadel

4.19.4, 1 October 2026

AGPL 3.0 (some parts Apache 2.0 or MIT)

PostgreSQL 14 to 18

Zitadel (company)

Authelia

4.39.28, 17 September 2026

Apache 2.0

SQLite, MySQL or PostgreSQL; Redis for sessions in HA

Community

Ory Kratos and Hydra

26.2.0, 20 March 2026

Apache 2.0; commercial OEL builds

SQL database

Ory (company)

Kanidm

1.11.2, 11 September 2026

MPL 2.0

Built-in replication, at most two nodes

Community

Dex

2.45.1, 3 March 2026

Apache 2.0

etcd, Kubernetes CRDs, SQL or memory

CNCF sandbox

The timeline, from release pages, project blogs and CNCF pages:

Date

Event

2 July 2013

First Keycloak commit; first stable release followed in 2014

25 July 2016

First Dex commit

11 October 2019

Keycloak.X (Quarkus) announced

14 December 2020

passbook renamed authentik in release 0.13

11 February 2022

Keycloak 17: Quarkus distribution fully supported

1 November 2022

Keycloak 20 removes the WildFly distribution

2 November 2022

Authentik Security launched; authentik licence changed to MIT

10 April 2023

Keycloak accepted into the CNCF as incubating

15 November 2023

Red Hat build of Keycloak 22 GA

4 October 2024

Keycloak 26.0: Organizations supported, user sessions persisted by default

13 March 2025

Zitadel announces the move to AGPL 3.0; v3.0.0 follows on 2 May 2025

31 July 2025

Zitadel 4.0.0 with the new Login V2 as default

27 October 2025

authentik 2025.10 removes Redis

1 October 2026

Keycloak 26.8.0: SCIM API and multi-cluster v2 supported

Four kinds of tool, not seven versions of one

Sort the tools by what they are first. Many bad choices come from comparing a full identity provider with a component.

Kind

Projects

What you still have to build

Full identity provider with admin UI

Keycloak, authentik, Zitadel

Mostly configuration and themes

Authelia

User management (LDAP or a YAML file)

Headless building blocks

Ory Kratos (identities), Hydra (OAuth2 and OIDC)

The login and account screens, and the glue

Identity server for infrastructure

Kanidm

Integrations beyond OIDC, LDAP and RADIUS

Federation broker

Dex

A real user store upstream

Keycloak today

From WildFly to Quarkus

Keycloak ran for years on the WildFly application server. In October 2019 the team announced Keycloak.X, aiming for easier configuration, faster start-up and lower memory use. A Quarkus preview shipped in Keycloak 12 (December 2020), Quarkus became fully supported in Keycloak 17 (February 2022), and Keycloak 20 removed WildFly (November 2022). Old standalone.xml knowledge is now history: configuration is CLI options, environment variables and conf/keycloak.conf.

Minor releases now come about every quarter: 26.4 on 30 September 2025, 26.5 on 6 January 2026, 26.6 on 8 April 2026, 26.7 on 9 July 2026 and 26.8 on 1 October 2026. Upstream also keeps patching older even lines, with 26.4.16 and 26.6.7 on 7 September 2026.

The Red Hat build of Keycloak

Red Hat’s product follows only the even upstream minors (26.0, 26.2, 26.4 and so on), roughly every six months, and patches each minor for about twelve months. RHBK 26.x became generally available on 13 November 2024, and its end dates depend on the RHBK 27.0 release. The older Red Hat Single Sign-On 7 had its maintenance extended to 30 June 2025. With Red Hat, plan upgrades on the even-minor rhythm; with upstream, plan for a new minor every quarter.

Architecture: database plus Infinispan

Keycloak stores realms, clients, users and sessions in a relational database. The supported list includes PostgreSQL 14 to 18, MySQL, MariaDB, Oracle, SQL Server, EnterpriseDB, Aurora PostgreSQL and Azure SQL. On top sits Infinispan: realms, users and authorisation data are cached locally on each node (10,000 entries each by default), a replicated work cache carries invalidations, and distributed caches hold sessions, action tokens and login failures. Since 26.1 the default jdbc-ping stack discovers cluster members through the database.

Version 26.8 stores brute-force login failures in the database by default, and makes multi-cluster v2 (--features=stateless) supported: clusters share a synchronously replicated database with no external Infinispan cluster. Multi-cluster v1 is deprecated. The multi-cluster guide is careful about scope: it was tested on two OpenShift clusters in one AWS region with Aurora PostgreSQL, and it is meant for teams that can “permit planned outages for maintenance”.

Realms and organisations

A realm is a full tenant with its own issuer URL, users, clients, identity providers and keys. One realm per customer works early and becomes painful as the count grows. Organizations, supported since 26.0, model B2B customers inside one realm, with email domains, invitations and per-organisation identity providers. 26.7 added dedicated organisation admin roles, and 26.8 lets one identity provider serve many organisations. For the Hyderabad team, one customer realm with one organisation per enterprise customer is now a real option.

The alternatives, one by one

authentik

authentik began as a hobby project called passbook in November 2018 and took its current name in December 2020. Authentik Security, a public benefit company funded by Open Core Ventures, launched on 2 November 2022, and the licence moved from GPL to MIT. Releases are numbered by year and month (2026.2, 2026.5, 2026.8), and the security policy supports only the last two.

You run a server, a worker and PostgreSQL. Redis was removed in 2025.10, and the release notes warn of “roughly 50% more database connections”, so check your limits or pooler first. Outposts add LDAP, RADIUS and proxy endpoints. The vendor’s pricing page lists OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy in the free edition, while features such as privileged access management, Entra ID and Google Workspace integration, and mTLS client certificates are Enterprise, at USD 5 per internal user per month.

Zitadel

Zitadel 1.0 shipped in April 2021, backed by a company of the same name. It is event-sourced: the database holds an event store plus projections, and the binary is stateless, so replicas are easy. The hierarchy is instance, organisation, project; extra virtual instances come through the System API, which suits a SaaS that offers identity to its own customers. It supports OIDC, SAML as an identity provider, LDAP as a login source and a SCIM 2.0 API still marked preview.

Version 3 (May 2025) switched to AGPL 3.0 and dropped CockroachDB, leaving PostgreSQL only. Version 4 (July 2025) made Login V2, a separate container, the default. The v3 announcement promised a major every three months; in practice v4 has stayed current for over a year, and v3 still gets fixes (3.4.15 in August 2026).

Authelia

Authelia is a companion to reverse proxies such as Traefik, Caddy, Envoy, NGINX and HAProxy: the proxy asks Authelia whether each request may pass, and Authelia shows a login portal with second factors. Users come from LDAP or a YAML file, and its roadmap still lists admin and user dashboards as active work. It is an OpenID Certified OIDC provider that its docs call an open beta. Sessions live in memory by default, so the docs recommend Redis for any HA setup. Passkey login is off by default (enable_passkey_login: false).

Ory Kratos and Hydra

Ory splits identity into servers: Kratos for identities, registration, login and recovery through APIs; Hydra, an OpenID Certified OAuth2 and OIDC server; Keto and Oathkeeper for permissions and proxying. None ships a login UI, so you build one. Since November 2025 versions follow the calendar (25.4.0, then 26.2.0 in March 2026). The servers are Apache 2.0, but zero-downtime upgrades and an optimised CockroachDB integration come with the commercial Ory Enterprise License, and Ory’s own docs suit open source to deployments “where occasional downtime for upgrades is acceptable”. Its release notes list B2B SSO, organisation login and multi-tenancy among paid offerings.

Kanidm

Kanidm serves a technical estate: OAuth2 and OIDC for web apps, read-only LDAP for older software, RADIUS for Wi-Fi and VPN, and SSH keys for Linux hosts. It prefers passkeys. The first stable release was 1.2.0 in May 2024. The policy is strict and clear: a release each quarter, four months of support each, upgrades only from the previous minor, replicas on the same version, and at most two nodes in replication. I found no SAML identity provider in its docs.

Dex

Dex, started in 2016 and a CNCF sandbox project since June 2020, is a federation broker. It issues OIDC tokens to apps such as Kubernetes tools and sends users to connectors like LDAP, GitHub, Google or SAML. Its docs warn that users who log in through the SAML connector get no refresh token. Storage can be etcd, Kubernetes CRDs, SQL or memory. Its last release, 2.45.1, is from March 2026.

Licences: read the files, not the badges

Project

What the licence file says

What it means in practice

Keycloak

Apache 2.0

Use, modify and offer as a service freely

authentik

MIT, except authentik/enterprise/ (EE licence) and website/ (CC BY-SA 4.0)

EE code in production needs a paid subscription

Zitadel

AGPL 3.0 only; proto/ and docs Apache 2.0; login app and client packages MIT

Network copyleft for modified versions; contributions under Apache 2.0

Authelia

Apache 2.0

No copyleft

Ory

Apache 2.0 for the open-source servers

Some features exist only in commercial OEL builds

Kanidm

MPL 2.0

File-level copyleft for changes to Kanidm files

Dex

Apache 2.0

No copyleft

The Zitadel change applies from v3 onwards. Get a legal reading of AGPL for your use case. For authentik, the practical risk is turning on an enterprise feature in production without noticing that it needs a subscription.

Protocols and features

Keycloak

authentik

Zitadel

Authelia

Ory Kratos + Hydra

Kanidm

Dex

OIDC provider

Yes

Yes, certified

Yes

Yes, certified, beta

Yes, Hydra certified

Yes

SAML identity provider

Yes

Not in docs

Not in open source

Not in docs

No, SAML only upstream

LDAP

Federates to LDAP and AD

LDAP server via outpost

LDAP as login source

LDAP as user backend

Not built in

Read-only LDAP server

LDAP connector

SCIM

API supported in 26.8

Yes

API in preview

Not in docs

Not in docs I read

SCIM endpoints exist; scope not checked

Not in docs

Passkeys and WebAuthn

Supported since 26.4

WebAuthn stage

Yes

Passkey login off by default

Kratos: yes

Preferred method

Via upstream only

Forward auth for proxies

Not since Louketo retired

Proxy outpost

Not built in

Core purpose

Oathkeeper

Not built in

Keycloak’s proxy, Louketo (formerly Gatekeeper), was retired in August 2020 with users pointed to OAuth2 Proxy. So to put SSO in front of an app with no login, Keycloak needs a separate proxy, while authentik and Authelia do it themselves.

Footprint and moving parts

Image sizes below are sums of compressed linux/amd64 layers from my drill. They show download weight, not memory use.

Keycloak 26.8.0

authentik 2026.8.3

Zitadel 4.19.4

Authelia 4.39.28

Kratos / Hydra 26.2.0

Kanidm 1.11.2

Dex 2.45.1

Image, compressed

265.4 MB

382.3 MB

53.3 MB, plus 69.3 MB login

28.3 MB

29.0 MB / 19.8 MB

59.7 MB

48.1 MB

External state

SQL database

PostgreSQL

SQL database, Redis for HA

SQL database

None beyond its replicas

Storage backend of your choice

Vendor’s small-setup guidance

Sizing guide

2 CPU, 2 GB

1 CPU, 512 MB (tests)

Not stated

Keycloak is the heaviest download but carries the most features. The lighter tools push some work, such as the login UI or user store, back to you.

Upgrades and migration pains

Project

Upgrade rule from the docs

Watch out for

Keycloak

Zero-downtime rolling updates for patch releases, supported and on by default since 26.6

Breaking changes listed per version in the upgrading guide

Keycloak Operator

OLM upgrades the operator automatically by default

The docs “strongly recommend” manual approval, because an operator upgrade also upgrades Keycloak

authentik

Do not skip major releases; no downgrades; outposts must match the server

2026.8 now trusts forwarded headers only from trusted proxy CIDRs

Zitadel

Run the setup phase for every new version, then start

The Helm chart runs init and setup as Jobs

Ory

Run migrations; zero-downtime upgrades are an OEL feature

Plan a maintenance window for open source

Kanidm

Upgrade one minor at a time; replicas must match

Four-month support window per release

Version 26.8 shows why you read the upgrading guide. Callers with only view-clients no longer see client secrets, initiating_idp is ignored by default, and identity provider mappers cannot grant admin roles unless allowAdminRoleMapping is enabled, which fixes CVE-2026-12388. All are sensible, and all can break automation that worked yesterday.

For production Keycloak, build the image once with your build-time options and start it with --optimized, so pods do not rebuild at start:

bin/kc.sh build --db=postgres --health-enabled=true --metrics-enabled=true
bin/kc.sh start --optimized --hostname=https://id.example.in \
  --https-certificate-file=/certs/tls.crt --https-certificate-key-file=/certs/tls.key

Running on Kubernetes

Keycloak’s upstream way is the Operator: OLM, plain manifests, kustomize since 26.7, and an experimental Helm chart for the operator in 26.8. There is no upstream Helm chart for the server, so many teams used Bitnami’s. Bitnami stopped pushing new images to its main Docker Hub catalog from 28 August 2025 and moved old ones to an unmaintained bitnamilegacy repository, so check what your Keycloak and PostgreSQL charts pull today. The other projects publish their own charts.

If you install the Keycloak Operator with OLM, set manual approval:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: keycloak-operator
  namespace: keycloak
spec:
  name: keycloak-operator
  channel: fast
  source: <your catalog source>
  sourceNamespace: <catalog namespace>
  installPlanApproval: Manual   # review release notes before each upgrade

Security track record

Every project here has had serious advisories; what matters is how fast fixes reach the versions you run.

Project

Advisory

Issue

Fixed in

Keycloak

CVE-2026-16443

SAML broker metadata import disabled response signature validation

26.4.14, 26.6.5, 26.7.1

Keycloak

CVE-2026-12388

Identity provider mapper could grant admin roles

26.8.0

Keycloak

CVE-2026-11800

JWT algorithm confusion in the JWT Authorization Grant

26.6.4

authentik

CVE-2026-47201

XML signature wrapping in SAML Source

2025.12.6, 2026.2.4, 2026.5.1

authentik

CVE-2026-57580

Account takeover via SAML NameID comment truncation

2026.2.6, 2026.5.5

Zitadel

GHSA-45f2-5q3r-xgg6 (critical; no CVE shown on the advisory)

Unauthenticated account takeover via passkey enrolment

3.4.14, 4.16.2

Zitadel

GHSA-jh92-5mrj-p2w2

Unauthenticated account takeover through predictable session IDs

4.19.2

Ory

CVE-2026-33503, CVE-2026-33504

SQL injection via forged pagination tokens in Kratos and Hydra admin APIs

26.2.0

Kanidm

GHSA-xxwr-vvr3-2g9f (critical)

Authenticated arbitrary writes to database content

1.9.4, 1.10.2

Authelia

CVE-2021-32637

Authentication bypass with malformed URIs on NGINX

4.29.3

Dex

CVE-2020-26290

SAML signature bypass from XML encoding issues

2.27.0

Two patterns stand out. SAML XML parsing and signature checks keep breaking, across Keycloak, authentik and Dex, so if you enable SAML, patch faster. And fixes land on supported lines only: authentik patches its last two releases, Kanidm its current one, and Keycloak’s 26.8.0 notes list three Keycloak CVEs plus dependency fixes. A year-old version is not “stable”; it is exposed.

A decision guide

Your situation

Reasonable first choice

Company-wide SSO with SAML and OIDC apps, LDAP or AD, and B2B customers

Keycloak, upstream or Red Hat build

Need a vendor contract and long support windows

Red Hat build of Keycloak

Small team, mixed apps, some without any login, want one friendly admin UI

authentik

SaaS that offers SSO to its own customers with deep tenant separation

Zitadel, after an AGPL review, or Keycloak with Organizations

Homelab or a few internal web apps behind Traefik or NGINX

Authelia

Your product needs custom sign-up and login screens, built by your developers

Ory Kratos and Hydra

Linux hosts, SSH keys, Wi-Fi and VPN for an engineering team

Kanidm

Kubernetes tools should use your existing GitHub, Google or LDAP login

Dex

A practical checklist

List every protocol in use: OIDC, SAML, LDAP, RADIUS and header-based apps.
Read the licence files of the exact version you will run, including enterprise directories.
Check the supported versions and put upgrades in the calendar.
Decide the tenant model (realms, organisations or instances) before onboarding the first customer.
Run a real database with backups and a tested restore; never production on dev-file or SQLite.
Pin images and charts, and confirm where they come from after the Bitnami change.
Use manual approval for operator upgrades, and back up the database before each one.
Subscribe to security advisories for your IdP and every outpost or connector you use.
Test deprovisioning end to end: disable a user and confirm access ends in every app.
Rehearse an upgrade and a rollback on a copy of production data, and time both.

Common mistakes

Treating Dex or Hydra as a user directory. Both expect identities to live somewhere else.
One realm per customer forever. It works at ten customers and hurts at five hundred; look at Organizations.
Letting OLM upgrade Keycloak at night. The operator upgrade also upgrades the server, and you cannot downgrade after a schema migration.
Ignoring connection counts. authentik after 2025.10 needs more PostgreSQL connections; size your pooler.
Running Authelia HA without Redis. In-memory sessions make each instance its own island.
Enabling SAML and then patching quarterly. SAML advisories are frequent; patch within days.

Drill: Keycloak, Hydra and seven charts, on one VM

I kept this local: no root, no containers, no cluster. On 7 October 2026, from about 10:34 to 10:39 PM IST, on a shared Linux VM with 8 vCPUs and 15 GB of RAM, I verified official downloads, ran two servers briefly on localhost, and rendered charts and manifests offline.

Verifying the downloads

The Keycloak 26.8.0 tarball (173,899,492 bytes) matched its published SHA-1 checksum. Keycloak publishes only SHA-1 and MD5 sums, not SHA-256, so I also checked the GPG signature: it was a good signature from the “Keycloak Bot” EdDSA key 861A B50E 8CC6 611F B6BC 01A6 B8F1 2EA2 6FD6 EEBA. I fetched that key from keyserver.ubuntu.com, and gpg warned that it is not certified by anyone I trust, so the signature proves integrity against that key, not who owns it. The Temurin JDK 25 tarball and Ory Hydra 26.2.0 matched their SHA-256 checksums.

Keycloak in dev mode

With JDK 25, kc.sh start-dev on 127.0.0.1 first rebuilt the server, then reported “started in 10.963s” (about 28 seconds of wall time). The process then used 575,892 KB of resident memory, about 562 MiB, with default JVM settings. Readiness was UP, the master realm’s discovery document listed 10 grant types (including password, implicit, token exchange and CIBA), and the SAML descriptor and admin console answered. Startup warned that the deprecated identity-brokering-api:v1 and twitter-broker:v1 features are on by default. A second start with changed options rebuilt again (about 23 seconds).

Then kc.sh start in production mode without certificates printed “Changes detected in configuration. Updating the server image.” and refused to start: “Key material not provided to setup HTTPS”. That is the right default, and another reason to build images once and start them with --optimized.

Hydra in dev mode

The standard Hydra binary refused DSN=memory because “sqlite3 support was not compiled into the binary”; the SQLite build worked. hydra serve all --dev was ready in about 200 ms and used 57,880 KB, about 57 MiB. A request to /oauth2/auth just redirected, since there is no login screen until you build one. Hydra also has a telemetry opt-out flag, --sqa-opt-out, worth setting deliberately.

What the charts and manifests install

Default render

Objects

Workloads

Resource requests set

Notes

Keycloak Operator 26.8.0 manifests

1 Deployment

Yes, 300m CPU, 450Mi

4 CRDs; no server until you add a Keycloak resource

authentik chart 2026.8.3

Server and worker

Bundled PostgreSQL off by default

Zitadel chart 10.3.0

2 Deployments, 3 Jobs

Chart app version 4.19.2, behind 4.19.4

Dex chart 0.25.2

1 Deployment

Role with all resources in dex.coreos.com

Ory Kratos chart 0.64.0

Deployment and courier StatefulSet

Non-root, read-only root filesystem

Ory Hydra chart 0.64.0

Hydra and hydra-maester

Adds the hydra-maester controller

Authelia chart 0.11.22

DaemonSet

Empty

Chart app version 4.39.24, behind 4.39.28

Only the Keycloak Operator set resource requests. Two charts lagged the latest release, so pin image tags yourself.

Honest limits: dev-mode memory is not production memory, and I set no heap limits. I measured no login throughput, clustering or real database. I did not run authentik, Zitadel, Authelia, Kanidm or Dex, so for those I have only image and chart data. No command in the drill was blocked.

What to unlearn and re-learn

Unlearn “Keycloak is a heavy WildFly app”. Re-learn that it is a Quarkus service with quarterly minors, persistent sessions and a stateless multi-cluster option.
Unlearn “open source IdP means free to use any way”. Re-learn to check MIT plus EE, AGPL and paid-only features per version.
Unlearn “one realm per tenant”. Re-learn Keycloak Organizations and Zitadel’s instance and organisation model.
Unlearn “lighter is simpler”. Re-learn that a light component often moves the login UI, user store or proxy back onto your team.

Revisit your identity provider before you standardise SSO

The Hyderabad team does not need to replace Keycloak just because a lighter tool exists. Learn what each tool really is: a full IdP, a proxy portal, a toolkit or a broker. Unlearn the WildFly habits and the idea that one licence covers all open source. Re-learn tenancy, upgrade rules and the SAML risk. Practise with a small drill and a rehearsed upgrade on copied data. Then apply it: patch on the project’s cadence, pick a tenant model, and only then put every application behind the same front door.

Sources

comments powered by Disqus

Releted Posts

Argo CD and Flux: revisit your GitOps controller before you scale or migrate

Manoj Shukla
October 7, 2026

A platform team in Pune looks after 14 Kubernetes clusters. Most of them are managed by one central Argo CD instance that the team set up in 2021.

Manoj Shukla
October 7, 2026

A platform team runs a three-node Vault Community cluster for about sixty services. In one week, a product group asks for its own isolated tenant, which in Vault means namespaces, an Enterprise feature, and finance asks whether the Enterprise quote is really needed.

Manoj Shukla
October 6, 2026

A platform team plans its Kubernetes 1.37 upgrade for the next sprint. The cluster checklist is green, except one line nobody owns: the ingress-nginx Helm chart, pinned at 4.