Keycloak vs authentik: The Honest 2026 Comparison

Last updated: July 2026

authentik wins on speed to a working setup: it ships a built-in forward-auth proxy, YAML config-as-code blueprints, a user-facing application launcher, and a visual flow editor, all on a stack that is just a server, a worker, and PostgreSQL. Keycloak wins on depth: standard token exchange (RFC 8693), DPoP, FAPI 2 Final, a published load-tested sizing formula, Java SPI extensibility, and built-in B2B features like Organizations, all free. Pick authentik to put SSO in front of a pile of self-hosted apps this afternoon; pick Keycloak when protocol depth, scale planning, or multi-tenant B2B is anywhere on your roadmap.

Most comparisons of these two are already stale

Here is the problem with almost every Keycloak vs authentik post in the search results: they compare 2024-era authentik, Redis and all, against a Keycloak that predates 26.2. Both pictures are wrong in 2026. authentik dropped Redis entirely in its 2025.10 release, and Keycloak has shipped standard token exchange, DPoP, FAPI 2 Final, and organization-scoped admin delegation since most of those posts were written.

So before the scorecard, a correction table. Every row was verified in July 2026:

If you are weighing more than these two, our open-source authentication comparison for 2026 ranks the wider field.

The honest scorecard

We run a managed Keycloak service, so you would expect this table to be rigged. It is not: authentik flat-out wins five of these ten rows, and pretending otherwise would only cost us your trust.

The rest of this post is the reasoning behind each row.

Where authentik genuinely wins

Built-in forward-auth proxy

This is authentik’s best feature and it is not close. The Proxy Provider runs inside an outpost, either embedded in the authentik server or as a standalone container, and speaks forward-auth natively to Traefik, Nginx, Caddy, and Envoy. It supports a single-application mode and a domain-level mode that covers every subdomain behind one provider, and all of it lives in the free tier (documented at docs.goauthentik.io).

The practical effect: you can put SSO in front of twenty self-hosted apps, including ones with no authentication support at all, without touching their code. Keycloak has no equivalent. The standard Keycloak pattern is to bolt on oauth2-proxy or an API gateway, which works fine in production but is one more component you deploy, upgrade, and debug.

Config-as-code blueprints

authentik treats YAML blueprints as a first-class way to define flows, stages, policies, users, and providers. You can apply them at startup, mount them into containers, or manage them through the API, which makes GitOps-style identity config feel native rather than bolted on.

Keycloak’s answer is realm JSON import/export plus the Keycloak Terraform provider (now maintained under the Keycloak GitHub org). That combination absolutely works, we use it daily, but it grew up around the platform rather than inside it. Blueprints are the more ergonomic starting point.

A real application launcher

authentik gives end users a launcher page out of the box: a policy-filtered dashboard where each user sees only the applications they are entitled to, each with its own launch URL, icon, and grouping. For an internal tools portal or a homelab landing page, it is exactly what you want and requires zero extra work.

Keycloak’s account console lists applications, but it is an account-management surface, not a portal. Teams that want a launcher in front of Keycloak usually build or deploy one separately.

Visual flow editor and faster first SSO

authentik models authentication as flows made of stages, gated by policies, and lets you assemble them visually with a flow inspector for debugging. In our experience the path from fresh install to first protected application is measurably shorter than Keycloak’s, mostly because there are fewer concepts standing between you and a login page.

Keycloak’s authentication flows are more powerful once you know them, but “required vs alternative vs conditional executions” is a learning curve, and nobody pretends otherwise.

Lighter operations for simple stacks

Since the 2025.10 release removed Redis, a production authentik deployment is three things: the server, a worker, and PostgreSQL 14-18. No cache cluster, no JVM heap tuning, no distributed-cache theory. For a single-node or small-HA deployment, that is genuinely less to operate.

Keycloak on a single node is not hard either (our Docker Compose generator will give you a working stack in a minute), but the moment you cluster it you meet Infinispan, and the moment you tune it you meet the JVM. That overhead buys real things, as the next section shows, but it is overhead.

Where Keycloak genuinely wins

Protocol depth

Keycloak 26.2 shipped standard token exchange per RFC 8693 as a fully supported feature, and 26.4 added supported DPoP (sender-constrained tokens) and FAPI 2 Final conformance, alongside fully supported passkeys. If you are building open banking APIs, service-to-service token flows, or anything a security auditor will read closely, this row is not a contest.

authentik covers the protocols most apps need: OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos, and its proxy. What it does not have is token exchange, DPoP, or any FAPI conformance program. For a homelab that gap is irrelevant. For a fintech it is disqualifying.

Published, load-tested scale numbers

Keycloak is the only platform in this comparison that tells you, in writing, how to size it: 1 vCPU per 15 password logins per second, 1 vCPU per 120 client-credential grants per second, 1 vCPU per 120 refresh-token requests per second, plus 150% headroom and roughly 1250 MB of RAM per pod. Behind that formula sits Infinispan-based clustering with documented multi-site deployment guides.

authentik publishes no equivalent load-tested sizing guidance. You can scale its server and worker replicas horizontally on shared PostgreSQL, and plenty of people do, but you are benchmarking it yourself. When someone asks “what does 500 logins per second cost”, only one of these projects has an official answer.

Java SPI extensibility at every layer

Every major Keycloak subsystem has a Service Provider Interface: user storage (federate a legacy user database that speaks neither LDAP nor SCIM), authenticators (custom MFA factors), event listeners (stream auth events to your SIEM), protocol mappers (claims from any source), and themes. If Keycloak does not do something, you can usually make it do that thing, in supported, documented ways. The complete Keycloak guide walks through what that architecture unlocks.

authentik’s extension surface is Python expression policies and property mappings. They are great for conditional logic and claim shaping, and far more approachable than writing Java. But the surface is narrower: you cannot, for example, implement a new storage backend or a new outpost type as a plugin.

Backing and the commercial path

Keycloak is a CNCF incubating project with a dedicated Red Hat engineering team, a quarterly-ish release train, and a paid support path through Red Hat build of Keycloak. It runs identity for banks, governments, and healthcare systems, which means the weird SAML edge cases were found and fixed years ago.

authentik is built by Authentik Security, Inc., a much smaller company, with authentik Enterprise as its commercial offering. To be fair to them: the project ships fast, the docs are good, and the community (heavily r/selfhosted and Discord) is energetic. But if your procurement team asks “who is behind this in ten years”, Keycloak has the easier answer.

B2B multi-tenancy built in

Keycloak 26.0 shipped Organizations: B2B tenancy with per-organization domains, membership, and invitation flows, inside a single realm. 26.2 added the rewritten fine-grained admin permissions, and 26.7 made those permissions org-scoped, so you can delegate administration of one customer organization to that customer. All of it is free.

On the authentik side, the closest capabilities, like directory sync, sit in the paid enterprise tier, and there is no direct equivalent of Organizations in the free core. If you are building B2B SaaS with per-customer SSO and delegated admin, Keycloak hands you the building blocks at no cost.

Architecture and licensing in July 2026

One licensing nuance worth being precise about, since most comparisons get it wrong in one direction or the other. authentik is not Apache 2.0, and it is not 100% MIT either: the core is MIT-licensed, while enterprise features in the same repository live under the separate authentik EE License and require a paid license to use. Everything you self-host for free is genuinely open source; the enterprise directory is source-available. Keycloak, by contrast, is Apache 2.0 end to end with no source-available carve-out.

What authentik’s own comparison says, and what it skips

Credit where due: authentik’s homepage comparison against Keycloak highlights three real differentiators. Its Application Proxy is built in where Keycloak needs an external component. Its RAC feature adds RDP, SSH, and VNC remote access through the browser, something Keycloak does not attempt at all (note that RAC is an enterprise-licensed feature, not part of the free core). And it offers vendor support for a self-hosted enterprise deployment, which Red Hat also does but most managed-only competitors do not.

What that table leaves out is the other half of this post: token exchange, DPoP, and FAPI conformance, published sizing and clustering guidance, SPI-level extensibility, and free B2B Organizations. Vendor comparison tables emphasize what the vendor wins. Ours carries the same risk, which is exactly why every contested claim here is version-stamped so you can check it.

Pricing models, not price tags

We do not print competitor dollar figures for self-hostable platforms because they change faster than blog posts do. The models, though, are stable and worth understanding.

authentik’s core is free to self-host under MIT. authentik Enterprise is priced per user per month, with a cheaper rate for external users than for internal ones, and is sold as a self-hosted deployment with support. Current numbers are on goauthentik.io/pricing.

Keycloak is free to self-host with no user limits and no enterprise edition; your costs are infrastructure and the engineering time to run it. If you want it run for you, paid paths are a Red Hat build of Keycloak subscription or a managed provider. That second option is what we do at Skycloak, and our pricing is public, so the same no-hidden-numbers rule applies to us.

Migration between the two is a project, not a feature

If you are hoping to swap one for the other with an import wizard, some honesty: that wizard does not exist in either direction.

• Neither project publishes an official “migrate from the other” guide. authentik’s integrations catalog does have a Keycloak entry, but it covers federating the two (using one as an identity source for the other), not replacing one with the other.
• Password hashes do not transfer cleanly. Importing foreign password hashes into authentik is a long-open feature request (authentik issue #4471), so moving to authentik means users set new passwords.
• Application configs, flows, and policies use incompatible models, so they are rebuilt, not converted.

The realistic playbook, in either direction: run both platforms side by side, move applications one at a time, and handle credentials either with a re-enrollment push (password reset at cutover) or just-in-time federation, where the old IdP stays alive as a brokered source and users migrate transparently on their next login. Budget it like a real project, because it is one.

How to choose

Choose authentik when:

• The job is putting SSO in front of self-hosted or legacy apps, many without native OIDC or SAML
• You want forward-auth, an app launcher, and YAML config as code out of the box
• Your stack is small, your team is small, and ops simplicity beats protocol depth
• Nothing on your roadmap says FAPI, token exchange, or B2B multi-tenancy

Choose Keycloak when:

• You are building enterprise single sign-on across a growing portfolio of OIDC and SAML apps
• You need token exchange, DPoP, FAPI 2, or anything else an auditor will ask about by RFC number
• B2B tenancy matters: Organizations and org-scoped delegated admin are free in Keycloak, paid or absent in authentik
• You want to extend the platform deeply (custom user storage, custom MFA, SIEM event streaming)
• You want load-tested sizing guidance and a vendor-backed commercial path before you commit

Both are solid choices for a straightforward portfolio of modern OIDC apps; at that point team preference (Python vs Java, UI-first vs config-first) is a legitimate tiebreaker. And if your real shortlist is open source versus a SaaS IdP, our Keycloak vs Okta comparison covers that decision.

Frequently asked questions

Is authentik easier to set up than Keycloak?

For your first working SSO setup, yes. authentik’s visual flow editor, built-in proxy, and three-service stack (server, worker, PostgreSQL) get you from install to a protected app faster than Keycloak’s admin console learning curve. The gap narrows as requirements grow: once you need clustering, token exchange, or B2B features, Keycloak’s extra upfront complexity starts paying for itself.

Does authentik still require Redis?

No. authentik removed the Redis dependency in the 2025.10 release; the current requirements are the server, a worker, and PostgreSQL 14-18. Any tutorial or comparison showing Redis in authentik’s docker-compose stack is describing a pre-2025.10 version and is out of date.

Is authentik really open source?

The core is, under the MIT license, and that covers everything you self-host for free, including OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos, and proxy providers. Enterprise features in the same repository are source-available under the separate authentik EE License and require payment. Keycloak is Apache 2.0 across the board with no enterprise carve-out.

Can Keycloak do forward auth like authentik?

Not by itself. Keycloak has no built-in forward-auth component, so the standard pattern is oauth2-proxy or an API gateway configured with Keycloak as the OIDC provider, wired to your reverse proxy’s forward-auth directive. It works well in production, but it is an extra component to run, where authentik’s Proxy Provider is built in and managed from its UI.

Which is better for enterprise SSO, Keycloak or authentik?

Keycloak, in most enterprise scenarios: it has deeper protocol support (RFC 8693 token exchange, DPoP, FAPI 2 Final), published load-tested sizing guidance, free B2B Organizations, and Red Hat plus CNCF backing. authentik Enterprise is a credible option when built-in application proxying or RDP/SSH/VNC remote access matters more to you than protocol depth, but for standards-heavy enterprise SSO, Keycloak is the safer default.