A focused identity layer for web applications
Authelia sits between users and web applications, usually through a reverse proxy's forward-authentication feature. The proxy asks Authelia whether a request is allowed, then passes it through, denies it, or sends the user to a login portal. This design can add one-factor or two-factor access to applications that have weak authentication, while supported applications can use Authelia directly as an OpenID Connect provider.
That combination is the project's appeal. A homelab or internal platform can put old dashboards behind a shared gate and give newer services proper delegated login. Access rules can match domains, paths, methods, networks, users, and groups. Policies can require no authentication, one factor, or two factors depending on the resource. Second-factor choices include WebAuthn security keys, passkeys, TOTP applications, and Duo push.
Authelia is not a general employee-directory product. First-factor identities come from LDAP, including Active Directory and FreeIPA, or from a YAML file containing password hashes. The file backend is reasonable for a small stable user list; LDAP is the natural route when accounts and groups already have an administrative home. Authelia stores its own state, registrations, and authorization data, but it does not replace every identity lifecycle system.
The container is the easy part
Official containers, static binaries, Debian packages, AUR packages, FreeBSD Ports, Kubernetes guidance, and a beta Helm chart provide several installation routes. The local Compose bundle demonstrates public, one-factor, and two-factor sites with self-signed certificates. A lighter bundle uses a file user database and SQLite, making a trial possible without deploying a full database cluster.
Production requires a longer checklist. Authelia needs a public authentication URL, correct cookie domains, secure random session and storage keys, an authentication backend, persistent storage, and a notification method for identity-verification flows. The reverse proxy must send the right headers and must prevent users from reaching protected services by another route. Every application needs either a correct forward-auth configuration or an OpenID client registration. DNS and TLS must already make sense.
The configuration system is strong. YAML options have detailed references, sensitive values can come from files or templates instead of sitting in the main configuration, and authelia config validate catches unknown keys, renamed settings, invalid values, and conflicting secret sources. The documentation clearly says validation does not test integrations. A syntactically valid access rule can still protect the wrong host, and a working login page does not prove that a backend cannot be reached around the proxy. Test allowed and denied cases from outside the trusted network.
High availability costs more than one replica
The simplest setup keeps sessions in memory and durable state in SQLite. That is appropriate for a single instance with backups, not for replicas that must agree. Authelia recommends Redis for stateless shared sessions in high-availability deployments and a remote PostgreSQL or MySQL database for storage. Operators then own three availability domains: Authelia, the database, and Redis, plus the reverse proxy in front.
This is normal for an authentication service, but it makes the phrase “add SSO” misleadingly small. Back up storage, protect the encryption key separately, test restoration, and decide what happens when SMTP, LDAP, Redis, or the database is unavailable. Because the login layer fronts many services, one configuration error or expired secret can create a broad outage. Rolling updates and readiness checks deserve rehearsal before the system becomes the only path into administrative tools.
OpenID Connect support is substantial and certified for several provider profiles. The documentation covers a large catalog of specific clients, which removes much guesswork around redirect URIs, scopes, claims, and client authentication. Still, the README describes the offering as beta, and the protocol guide says Dynamic Client Registration and Session Management remain planned goals. Certification proves tested protocol profiles, not support for every optional feature an application might expect.
Security posture and project health
Authelia's threat model is unusually useful because it states its trust boundary plainly. The service assumes a trusted internal network and relies heavily on the reverse proxy. Identity headers sent to backends are unsigned, so an attacker able to reach a backend directly or impersonate the trusted path may bypass the intended check. Network segmentation and proxy configuration are part of the security control, not surrounding conveniences.
The latest release, v4.39.20 on May 26, 2026, fixed two security issues involving domain canonicalization in access rules and username canonicalization with LDAP basic authentication. Users were told to update promptly. This is evidence of both real security risk and a functioning disclosure and patch process. Authentication software will attract scrutiny; responsible maintenance matters more than pretending vulnerabilities never occur. The README also says the team is raising funds for an external security audit or penetration test, a relevant procurement fact for higher-assurance environments.
The repository was pushed on August 17, 2026, with issues and pull requests updated throughout the day. Its 128 open items include both issues and pull requests, and active work covers dependencies, sessions, storage, authorization, documentation, and service readiness. The May release date is not evidence of neglect. Authelia has existed since 2016, has broad adoption, and shows sustained engineering activity.
The decision
Choose Authelia when the main job is protecting self-hosted web applications behind a proxy and when file or LDAP identities fit. It offers more security depth and better documentation than a thin login shim without demanding the full administrative world of Keycloak. Choose authentik or Keycloak when visual identity administration, federation, and broader user lifecycle features dominate. Choose OAuth2 Proxy when an external provider already exists.
Authelia is mature enough to recommend and important enough to operate carefully. Begin with the lite deployment, map every trust boundary, then graduate to production storage and sessions only after bypass, recovery, and upgrade tests pass.