Authelia is an open-source authentication and authorization server written in Go that provides single sign-on and multi-factor authentication for web applications through a web portal, aimed at self-hosters and platform teams who need to protect services sitting behind a reverse proxy.

What it is

Authelia is an authentication and authorization server that acts as a companion for reverse proxies. Rather than authenticating users inside each application, it sits in front of them and allows, denies, or redirects requests, presenting a web portal where users complete login and second-factor challenges. It is written in Go, licensed under Apache-2.0, and distributed both as a standalone service and as a container. The project lives in the cloud-native and self-hosting ecosystem, with first-class integrations for Docker and Kubernetes and out-of-the-box compatibility with Traefik and Caddy.

The concrete problem it solves is the fragmentation of authentication across a fleet of self-hosted or internally hosted web applications. Instead of each service carrying its own login, session, and second-factor logic, Authelia centralizes that responsibility and delegates the decision to the proxy in front of the app. It also exposes OpenID Connect 1.0 and OAuth 2.0 so that applications can consume it as an identity provider directly. The result is one portal, one set of access rules, and one place to enforce second factors across every protected endpoint.

Key capabilities

• OpenID Connect 1.0 and OAuth 2.0 provider, OpenID Certified™ for the Basic OP, Implicit OP, Hybrid OP, Form Post OP, and Config OP profiles.
• Post-Quantum Cryptography readiness.
• Multiple second factors: FIDO2 WebAuthn security keys such as a YubiKey, Time-based One-Time passwords, and Mobile Push Notifications via Duo.
• Passwordless authentication using WebAuthn passkeys.
• Fine-grained access control rules matching subdomain, user, user group membership, request URI, request method, and network, with a choice between one-factor and two-factor policy per rule.
• Access restriction after too many invalid authentication attempts, plus password reset with identity verification by email confirmation.
• High availability through a remote database and Redis as a highly available key-value store, and native proxy integration via Traefik ForwardAuth and the Caddy forward_auth directive.

Who uses it and how

• Self-hosters running a reverse proxy in front of multiple services, who want a single login and second-factor prompt instead of per-application credentials.
• Users of the LinuxServer SWAG container, which ships curated Authelia configuration alongside a published setup guide.
• Kubernetes operators deploying through ingress-nginx, the Traefik Kubernetes CRD or Ingress, Istio, or Envoy Gateway, with Helm chart installation available in beta.
• Teams already standardized on Duo who want mobile push approval as their second factor.
• Organizations that need basic authentication preserved for endpoints governed by a one-factor rule while applying two-factor policy elsewhere.

Getting started

Install as a standalone service from the AUR, APT, or FreeBSD Ports, or use a static binary or .deb package from the releases page. Container deployment is available on Docker and Kubernetes, with orchestration via the Helm chart in beta.

How it compares

No comparable single sign-on or identity provider tools are named in the facts provided here, so no direct product comparison can be made. Among the integrations the project does name, it occupies a distinct position: it is not a reverse proxy like Traefik or Caddy, and not a second-factor vendor like Duo, but the authentication layer that sits between them. On that basis it stands alone in this registry.

When to use it — and when not to

A self-hoster must operate supporting infrastructure: a remote database and Redis are required for the highly available configuration, and password reset with identity verification depends on outbound email confirmation. Anyone unwilling to run and maintain a database, a key-value store, and mail delivery alongside the authentication server itself should look elsewhere. Note also that the OpenID Connect offering, the Helm chart, and the Kubernetes integration paths are all described as beta, so teams requiring only generally available components should weigh that before adopting.