authentik vs Authelia vs Keycloak

Authelia is a companion to your reverse proxy, not a standalone front door. The proxy asks Authelia whether each request may pass, and unauthenticated users are redirected to Authelia's login portal. That keeps the moving parts small, but it also means the proxy you already run must be one Authelia supports, such as Traefik, Caddy, NGINX or HAProxy, and every protected site must be served over HTTPS because Authelia's session cookies require it. Confirm that your proxy and certificate process fit that model before you commit, because Authelia does not support plain HTTP.

authentik is a fuller identity provider with more running parts. A deployment has a server container (core with an embedded outpost), a worker container for background tasks, and PostgreSQL, which holds all configuration and data except uploaded files. The 2025.10 release notes state that authentik no longer uses Redis, moving caching, tasks, sessions and WebSocket work to PostgreSQL, and warn of roughly 50% more PostgreSQL connections after upgrading. For operators, the practical checks are database sizing, connection limits and whether your team wants to run the Compose layout the docs describe for test and small-scale production, or a Kubernetes install.

Keycloak asks for the most infrastructure. Production use needs a supported relational database, and the default dev-file database is for development only. Its Keycloak Operator is installed through Operator Lifecycle Manager, which Keycloak recommends, or with kubectl, and the Operator documentation strongly recommends manual approval mode for updates. High availability designs, a single cluster optionally spread across availability zones or the v2 multi-cluster design, both need a synchronously replicated database. Plan for database administration, Operator upgrades and cluster testing, and confirm which high availability pattern your database and sites can support.

Start by deciding where your users will live, because the three platforms answer that question differently. Authelia authenticates against either an LDAP directory such as OpenLDAP, OpenDJ, FreeIPA or Microsoft Active Directory, or a YAML file of users with hashed passwords. That file-based option is simple to version and review, but every user change is a file edit and a reload, so it suits a small, stable group. Authelia stores user preferences, second factor device registrations and authentication logs in PostgreSQL, MySQL or local SQLite, so the users themselves stay in the directory or file while Authelia holds only their login state. authentik keeps its own internal users and manages them through providers and flows in its admin interface, with configuration and data stored in PostgreSQL. If your people already sit in a directory, check whether authentik's LDAP source setup fits your schema before you build a parallel user store. Keycloak sits in between: it federates users from LDAP or Active Directory and can broker logins to external OpenID Connect or SAML identity providers, so a partner or a corporate IdP can authenticate people who never get a local Keycloak account.

Second factors differ in scope. Authelia offers one-time passwords, security keys and passkeys, and Duo mobile push as second factors, and adds self-service password reset and account banning after too many failed attempts. Confirm which of these your Authelia version and user backend combine correctly, since the Duo option depends on your Duo account and the backend you choose. authentik and Keycloak handle second factors inside their own authentication flows and policies, so the question for both is whether the methods your staff need are configured in the flows you plan to run. Check that passkey and hardware key enrollment works for users who lack a local account in a federated setup, because a brokered user may not be able to register a factor in the platform they signed into.

Before you commit, run a short proof of concept with one directory source and one external login. Confirm which system is the source of truth for group membership, how a disabled account in the directory stops access everywhere, and where second factor registrations are stored and backed up. Keycloak's brokering and federation are the strongest fit when partners or external identity providers must sign in, while Authelia's file or LDAP backend is the lightest option when the goal is protecting self-hosted sites behind a reverse proxy. Ask your chosen vendor or implementation partner to document the failure path for each backend, so an outage in the directory or identity broker is understood before go-live.

Switching SSO later is mostly re-registration work, not a data migration. Every application that trusts the identity provider has to be re-pointed: OIDC clients or SAML service providers in authentik and Keycloak, forward-auth rules in Authelia, and the reverse proxy configuration that sends unauthenticated requests to the login portal. Sessions do not carry across, so users sign in again on cutover. Before committing, list every protected app and record whether it uses OIDC, SAML, LDAP or proxy-based protection, because each protocol maps to a different replacement step. Ask each vendor, and your implementation partner, what export options exist for client definitions, flows and policies, and whether they round-trip into another product. Do not assume a configuration export is portable.

The lock-in surface differs by product. Keycloak's protocol coverage (OpenID Connect, OAuth 2.0 and SAML 2.0) gives the widest set of client types to re-register, and its brokering of external identity providers means upstream trust relationships must be rebuilt in any replacement. authentik stores configuration, users and data in PostgreSQL, so a move is a database-level and admin-level exercise, and its proxy and LDAP providers shape how legacy apps are wired. Authelia is the lightest to remove because it holds user preferences, second factor registrations and logs in PostgreSQL, MySQL or SQLite, but it has no SAML support, so SAML-only applications would need a different front end regardless. Second factors are the item most likely to force user action: confirm with each vendor whether TOTP, WebAuthn or passkey registrations can be migrated or must be re-enrolled.

Paid features add a second lock-in layer. authentik's Google Workspace, Microsoft Entra ID, mTLS, privileged access management, password history and enhanced audit logging sit in the Enterprise edition, and the pricing page lists the paid tiers. If your environment depends on those, the replacement must cover the same controls, and your audit evidence should be exported before any subscription lapses. Keep a written inventory of which features you use, which are paid, and which are community features, then ask each vendor how a licence change or downgrade affects configuration access. Plan the switch as a fixed-scope project with a cutover window and a rollback path, and get the export and re-enrolment steps confirmed in writing before the first application is moved.