Keycloak vs Authentik: Which Open-Source Identity Provider?

Last updated: June 2026

Both Keycloak and Authentik are fully open-source identity providers with Apache 2.0 licenses, but they are built on different technical foundations and optimized for different use cases. Keycloak is a Java/Quarkus platform with enterprise-grade protocol breadth, mature federation support, and a Service Provider Interface (SPI) system that allows deep extensibility at every layer. Authentik is a Python/Django platform best known for its visual flow editor and built-in forward-auth outpost architecture that makes it easy to gate self-hosted or homelab applications without modifying the apps themselves. Choose Keycloak when you need enterprise federation depth, broad standards compliance, and production scalability; choose Authentik when your primary goal is proxy-based application protection with a developer-friendly configuration UI.

Architecture and Runtime

The most fundamental difference between Keycloak and Authentik is the technology stack. This influences performance characteristics, deployment footprint, and how you extend each platform.

Keycloak 26.x runs on Quarkus, a supersonic, subatomic Java framework that dramatically reduced Keycloak’s startup time and memory footprint compared to the legacy WildFly runtime. A typical production Keycloak instance starts in under three seconds and can be tuned to run on as little as 512 MB of heap in lightweight deployments, though production clusters typically allocate 1-2 GB per node. Keycloak stores all configuration in a relational database (PostgreSQL recommended in production) and supports clustering via Infinispan for distributed session management.

Authentik is built on Python with Django and Celery for background task processing. It uses PostgreSQL as its primary store and Redis for caching and task queuing. The overall footprint of Authentik is somewhat lighter than a full Keycloak cluster, which makes it attractive for homelabs and small-scale self-hosted environments. However, Python’s GIL and Django’s synchronous-first model mean Authentik generally handles high concurrency with more horizontal scaling than Keycloak’s JVM-based threading model.

Dimension	Keycloak 26.x	Authentik 2024.x
Language / runtime	Java 21 + Quarkus	Python 3.12 + Django
Background tasks	Built-in	Celery + Redis
Primary data store	PostgreSQL (MariaDB supported)	PostgreSQL
Session distribution	Infinispan (embedded or external)	Redis
Startup time	~3 seconds (Quarkus)	~15-30 seconds
Min memory (single node)	~256 MB heap (lightweight mode)	~500 MB (server + worker)
License	Apache 2.0	MIT

For a broader look at how both compare within the wider open-source identity landscape, see the open-source authentication comparison for 2026.

Protocol Support

Protocol coverage is one of Keycloak’s strongest selling points. Keycloak has implemented and maintained OIDC, OAuth 2.0, SAML 2.0, and LDAP/Kerberos support through many years of production use across thousands of enterprise deployments.

Authentik supports OIDC, OAuth 2.0, SAML 2.0, LDAP (via a dedicated LDAP outpost), and RADIUS (also via an outpost). For the vast majority of modern application integrations, both platforms offer comparable protocol coverage.

Where Keycloak pulls ahead is in edge-case depth: fine-grained OAuth 2.0 features such as DPoP (Demonstrating Proof of Possession), rich authorization policy evaluation via its Authorization Services module, and advanced SAML artifact binding configurations that some enterprise vendors require. Keycloak’s FAPI (Financial-grade API) compliance and ongoing investment in OpenID for Verifiable Credentials (OID4VC) reflect the project’s commitment to standards leadership.

Protocol / Feature	Keycloak	Authentik
OpenID Connect / OAuth 2.0	Full, including DPoP, PKCE, RAR	Full, PKCE supported
SAML 2.0	Full (SP + IdP, artifact binding)	Full (SP + IdP)
LDAP (as directory)	Built-in via LDAP provider	Via LDAP outpost
RADIUS	No built-in	Via RADIUS outpost
Kerberos / SPNEGO	Yes	No
FAPI compliance	Yes (1.0, 2.0 draft)	No
Authorization Services (UMA)	Yes	No
WebAuthn / Passkeys	Yes	Yes
Social / OIDC brokering	Yes	Yes

For teams that rely on LDAP directory integration, the Keycloak LDAP integration guide covers the full configuration walkthrough including attribute mapping and sync strategies.

Forward-Auth and Reverse-Proxy Integration

This is the area where Authentik has the most distinct advantage over Keycloak.

Authentik ships with a first-class concept called an outpost — a lightweight sidecar or standalone service that runs alongside your applications. The Proxy Provider outpost implements forward-auth, which means you can protect any web application (regardless of whether it supports OIDC or SAML natively) simply by routing traffic through Authentik’s proxy. This is especially powerful for legacy applications, internal dashboards, or any tool that does not have built-in authentication support.

The Authentik proxy outpost integrates directly with Nginx, Traefik, and Caddy reverse proxies using their native forward-auth directives. Configuration is done through Authentik’s web UI rather than nginx.conf edits. This makes Authentik exceptionally popular in homelab communities and for self-hosted application stacks where the goal is to add SSO to dozens of apps quickly without touching each application’s code.

Keycloak does not ship a proxy or forward-auth component. To achieve forward-auth with Keycloak, you need a separate tool such as oauth2-proxy or a gateway like Kong or Gloo that integrates Keycloak as its OIDC provider. This is a well-understood pattern in production, but it requires additional operational components. The guide to running Keycloak behind a reverse proxy covers TLS termination and the KC_PROXY header configuration Keycloak needs when sitting behind Nginx or Traefik.

Forward-Auth Scenario	Keycloak	Authentik
Built-in proxy outpost	No	Yes
Nginx forward-auth	Via oauth2-proxy	Native (outpost)
Traefik forward-auth	Via oauth2-proxy	Native (outpost)
Caddy forward-auth	Via oauth2-proxy	Native (outpost)
Apps requiring OIDC/SAML	Direct integration	Direct + Proxy Provider
Legacy apps (no auth support)	Needs gateway/proxy	Yes (Proxy Provider)
LDAP outpost	No	Yes
RADIUS outpost	No	Yes

If your environment is primarily a cluster of self-hosted applications that need SSO protection without code changes, Authentik’s outpost model delivers this with significantly less operational overhead than a Keycloak + oauth2-proxy combination.

Flow Customization and Authentication Policies

Both platforms support customizable authentication flows, but the interface and extension model differ substantially.

Authentik’s Flow Builder is a visual, node-based editor where you construct authentication sequences by connecting stages (e.g., identification, password, MFA, consent, source enrollment). Each flow is a directed graph of stages with policies controlling which branches execute. This visual approach is intuitive and makes it easy to build complex conditional flows — such as requiring MFA only for admin users, or presenting a custom enrollment form to new social-login users — without writing code. Flows are configured entirely through the Authentik web UI.

Keycloak’s Authentication Flows use a hierarchical execution model configured in the admin console. Each realm has configurable flows (browser flow, registration flow, direct grant flow, etc.) composed of required, alternative, conditional, and disabled executions. Keycloak ships with authenticators for OTP, WebAuthn, passkeys, email verification, and more. The real power comes from the SPI: you can write custom authenticators in Java, package them as JAR files, and drop them into Keycloak’s providers/ directory. Custom SPIs give you access to the full Keycloak session context, user model, and realm configuration at authentication time.

The tradeoff: Authentik’s flow builder is faster to configure visually; Keycloak’s SPI gives deeper programmatic control for complex enterprise logic.

Flow Feature	Keycloak	Authentik
Configuration method	Admin console (hierarchical)	Visual flow editor (graph)
Custom logic	Java SPI (providers/)	Python expressions + policies
Conditional branching	Conditional sub-flows	Policy-based stage conditions
Custom UI pages	Freemarker themes / SPI	Flow stages + custom HTML
Headless / embedded login	Yes (custom JS adapter)	Limited
Post-login actions	Required actions (SPI)	Flow stages

For a deep dive into what Keycloak’s architecture makes possible beyond authentication flows, see what is Keycloak: a complete guide.

Identity Federation and Brokering

Federation — the ability to authenticate users through external identity providers and map their identities into your system — is a core capability of both platforms, but Keycloak’s maturity here is noticeable.

Keycloak supports social login brokering (Google, GitHub, Facebook, and dozens more via OIDC/SAML), enterprise federation via LDAP and Active Directory, and SAML IdP brokering for enterprise SSO chains. Its identity brokering model allows complex scenarios such as account linking (mapping an external IdP identity to an existing local user), first-login flows (running additional steps the first time a brokered identity logs in), and post-broker login flows. Keycloak also supports Kerberos/SPNEGO for Windows SSO without requiring users to re-authenticate.

Authentik supports OIDC, SAML, and LDAP sources (inbound federation), and handles social login through a source-based model similar to Keycloak’s brokering. It does not support Kerberos/SPNEGO natively. Authentik’s enrollment flows for new federated users are handled through the flow builder, which is flexible but requires more manual assembly than Keycloak’s built-in first-login flow configuration.

For teams comparing Keycloak’s federation capabilities against another enterprise-grade platform, the Keycloak vs FusionAuth comparison covers federation and licensing differences in detail.

Deployment and Operations

Keycloak

Keycloak’s Quarkus distribution ships as a single binary or OCI container image. Clustering requires an Infinispan-compatible cache layer (embedded Infinispan is suitable for small clusters; external Infinispan or Red Hat Data Grid is recommended for large deployments). The official Helm chart supports Kubernetes deployments with horizontal pod autoscaling.

Key operational considerations:

• Database migrations run automatically on startup (can be disabled for controlled environments)
• The KC_PROXY_HEADERS configuration is required when behind a reverse proxy (set to xforwarded or forwarded)
• Health, metrics, and management endpoints are available on a separate management port (9000 by default)
• Keycloak’s admin REST API is comprehensive and well-documented, enabling full infrastructure-as-code management via Terraform, Ansible, or the official Keycloak Terraform provider

Authentik

Authentik is distributed as a Docker Compose stack (server + worker + PostgreSQL + Redis) and as a Helm chart for Kubernetes. The architecture is straightforward: the Django web server handles HTTP requests, Celery workers handle background tasks (email sending, LDAP sync, etc.), and outposts run as separate containers. Outposts can be managed by the Authentik server (embedded mode) or run as standalone services.

Operational considerations:

• Outpost configuration changes propagate via a WebSocket connection from outpost to server
• LDAP and RADIUS outposts each require their own port exposure
• Authentik’s built-in backup is limited; external database backup strategies are recommended for production
• Authentik’s API is OpenAPI-documented and supports Terraform via a community provider

Deployment Aspect	Keycloak	Authentik
Container images	Official (quay.io/keycloak)	Official (ghcr.io/goauthentik)
Kubernetes Helm chart	Official	Official
Database	PostgreSQL / MariaDB	PostgreSQL only
Cache / session layer	Infinispan (embedded or external)	Redis
High availability	Native clustering	Multiple server replicas + shared Redis
Terraform provider	Official (mrparkers/keycloak)	Community (goauthentik/authentik)
Managed hosting	Red Hat SSO, Skycloak	No major managed offering

One honest weakness of self-hosted Keycloak is operational complexity. Cluster tuning, JVM heap sizing, Infinispan configuration, database connection pooling, and theme management all require time and expertise. Teams that want Keycloak’s enterprise capabilities without the ops burden increasingly turn to managed Keycloak providers. Skycloak’s managed Keycloak hosting handles infrastructure, upgrades, clustering, and backups so your team can focus on integration rather than operations.

Extensibility

Keycloak’s SPI system is one of its defining advantages at enterprise scale. Every major subsystem — authenticators, user storage, event listeners, identity providers, token mappers, theme resources — has a defined interface you can implement in Java. SPIs are packaged as JAR files and deployed to the providers/ directory, after which Keycloak picks them up on the next build (the kc.sh build step compiles the Quarkus application with your providers included).

This means you can:

• Connect Keycloak to a legacy user database that does not support LDAP by implementing a UserStorageProvider
• Add a custom MFA factor (hardware token, biometric system) by implementing Authenticator and AuthenticatorFactory
• Emit authentication events to a SIEM by implementing EventListenerProvider
• Add custom token claims from any data source by implementing ProtocolMapper

Authentik’s extension model relies on Python expressions within policies and custom stages written in Python. This is more accessible for teams without Java experience, but the extension surface is narrower than Keycloak’s SPI system. Authentik does not support custom outpost types via a plugin interface — outpost types (proxy, LDAP, RADIUS) are hardcoded in the server.

Community and Maturity

Keycloak is one of the most widely deployed open-source identity platforms in the world. It is sponsored by Red Hat (IBM), which employs a dedicated engineering team and releases regular minor versions (targeting every three months for major features) with long-term support releases. The Keycloak GitHub repository has over 22,000 stars, and the community forum and mailing lists are active with both community members and Red Hat engineers.

Authentik is a younger project, started in 2019, with a growing community concentrated in homelab and self-hosting communities (Subreddit r/selfhosted, Discord). The GitHub repository has over 14,000 stars. Goauthentik GmbH, the company behind Authentik, offers Authentik Enterprise with additional support and compliance features.

The maturity gap matters most in edge cases: Keycloak’s years of production use across banks, healthcare systems, and governments mean that unusual SAML quirks, LDAP dialects, and protocol edge cases have been encountered and fixed. Authentik’s community is smaller and its bug surface in complex enterprise scenarios is less well-explored.

Use Cases: Which Should You Choose?

Choose Keycloak when:

• You need enterprise SAML federation with complex IdP chains or artifact binding
• Your organization requires FAPI compliance (financial services, open banking)
• You want to extend the identity platform deeply via Java SPIs (custom user storage, custom MFA)
• You are integrating with Active Directory via Kerberos/SPNEGO
• You need a mature, Red Hat-backed platform with proven production pedigree at scale
• Your team plans to use Keycloak as the central IdP for dozens of OIDC/SAML applications

Choose Authentik when:

• Your primary goal is to add SSO to self-hosted or homelab applications without modifying each app
• You prefer a visual flow builder over code-based extension
• You are protecting a mix of modern and legacy applications behind a reverse proxy
• Your team is more comfortable with Python than Java
• You want built-in LDAP and RADIUS outposts with minimal configuration

Both are viable when:

• Protecting modern applications that support OIDC/OAuth 2.0 natively
• Implementing social login or SAML IdP integration for a small to medium application portfolio
• Self-hosting in a Kubernetes environment

Frequently asked questions

Is Authentik better than Keycloak?

Neither platform is universally better — they excel in different scenarios. Authentik is often considered easier to get started with, particularly for proxy-based application protection and visual flow configuration. Keycloak is generally the stronger choice for enterprise environments that require deep protocol compliance, Java-based extensibility, Kerberos integration, or a platform with long-term Red Hat backing and a large enterprise community. For production identity platforms serving thousands of users across complex federation chains, Keycloak’s maturity and extensibility are difficult to match.

Does Authentik support SAML?

Yes. Authentik supports SAML 2.0 both as a service provider (SP) and as an identity provider (IdP). You can configure SAML applications (service providers) in Authentik and use SAML sources to federate identities from external SAML IdPs. Authentik’s SAML support covers the common use cases including signed requests, encrypted assertions, and SP-initiated flows. For advanced SAML scenarios such as artifact binding or FAPI-level compliance, Keycloak has broader coverage.

Can Authentik act as a reverse proxy?

Authentik does not replace a reverse proxy (Nginx, Traefik, Caddy) but it provides a Proxy Provider outpost that integrates with those proxies via forward-auth. When a user accesses a protected URL, the proxy checks with the Authentik outpost whether the user is authenticated. If not, the outpost redirects them through an Authentik flow. Once authenticated, the proxy passes the request through with user headers injected. This makes it straightforward to add authentication to any HTTP application without modifying the application itself.

Does Keycloak have a forward-auth proxy?

Keycloak does not ship a forward-auth component. The standard approach is to deploy oauth2-proxy in front of your applications and configure it to use Keycloak as its OIDC provider. oauth2-proxy supports Nginx, Traefik, and other proxies via forward-auth directives, achieving the same outcome as Authentik’s built-in outpost but requiring an additional component to manage. Some teams use API gateways (Kong, Gloo, Istio with OIDC plugins) for the same purpose in Kubernetes environments.

Can you migrate from Authentik to Keycloak?

Migrating between identity providers is always a significant project because users, groups, application configurations, and authentication flows all need to be recreated. Authentik’s export format and Keycloak’s import format are not compatible, so migration requires scripting against both APIs. User passwords cannot be migrated if stored as hashed values (both platforms hash passwords, and the hash formats differ). The practical path for most teams is to configure Keycloak alongside Authentik, migrate applications one by one, and handle user re-enrollment via a password reset flow rather than trying to transfer hashed credentials.

The managed Keycloak option

Running Keycloak in production — even for relatively small deployments — involves ongoing work: version upgrades (Keycloak releases every few months), database backups, JVM tuning, TLS certificate rotation, and monitoring. For teams that want Keycloak’s enterprise capabilities without the operational overhead, managed Keycloak is increasingly the right answer.

Skycloak provides managed Keycloak hosting with automatic upgrades, clustered infrastructure, daily backups, and a 99.9% uptime SLA. You get the full power of Keycloak’s protocol support, SPI extensibility, and federation capabilities without running the infrastructure yourself. Plans start with a generous free tier for development and low-traffic production workloads.

If Keycloak’s feature set is what you need but self-hosting feels like too much overhead, explore Skycloak’s managed hosting plans to see whether a managed deployment fits your team’s budget and operational constraints.