Authelia 4.39: An OpenID Certified SSO Portal That Puts the Reverse Proxy in Charge

What Authelia Actually Solves

Authelia sits in front of your web applications as a companion to a reverse proxy. It answers one question per request: should this user be allowed through? The proxy forwards the request to Authelia, which either allows it, denies it, or redirects the user to a login portal. That portal handles single sign-on and second-factor verification. The target audience is a homelab owner or a small operations team running nginx, Traefik, Caddy, HAProxy, Envoy, or Skipper who wants centralized authentication without adopting a full identity platform. It is not an identity provider in the Okta or Keycloak sense. It does not store user directories or issue tokens for arbitrary APIs. It guards the front door of your web services.

The Architecture: ForwardAuth and a Policy Engine

The README describes Authelia as allowing, denying, or redirecting requests. The mechanism is the forward_auth middleware that Traefik and Caddy expose, and the equivalent auth_request directive in nginx. When a request hits the proxy, the proxy sends a subrequest to Authelia with the original request details. Authelia evaluates its access control rules, which match on subdomain, user, group membership, request URI, request method, and network. Each rule can require one factor or two factors. If the session is valid, Authelia returns a positive response and the proxy forwards the original request. If not, it redirects to the portal. The portal then handles the login flow, including WebAuthn security keys, TOTP apps, or Duo push notifications. The session state lives in a remote database and Redis, which the README says enables high availability. That split matters: Authelia is stateless enough to scale behind a load balancer, but it depends on those external stores.

OpenID Connect: Certified but Still Beta

Authelia holds OpenID Certified status for the Basic, Implicit, Hybrid, Form Post, and Config OP profiles. That certification is a real, verifiable claim, and it is unusual for a self-hosted project. But the README is honest about the contradiction: the OpenID Connect offering is still on the roadmap as a beta. The certification covers the protocol conformance, not the operational maturity. For an engineer, that means the OIDC endpoints and flows should behave correctly in conformance tests, but the feature set may still shift. If you plan to use Authelia as an OIDC provider for applications that require standard claims or dynamic client registration, verify those specific capabilities against the integration guide before committing. The certification is a strong signal, but it does not remove the beta label.

Getting It Running: Docker Compose and Helm

The README points to docker compose bundles as the starting point. There are two variants. The Local bundle is for testing without internet exposure; it uses self-signed certificates and domains defined in your hosts file. The Lite bundle is for a server exposed to the internet, with DNS setup and LetsEncrypt certificates. Both come with self-signed certificates by default, so you must customize them. The README warns that you will have to adapt the compose files to your needs. For Kubernetes, there is a Helm chart, but it is marked beta. The chart works with ingress controllers and ingress configurations, and it supports several controllers: ingress-nginx, Traefik CRD, Traefik Ingress, Istio, and Envoy Gateway. The concrete commands are not in the README, but the documentation site hosts the full get-started guide. The key point is that Authelia is not a single binary you run and forget. You configure a YAML file, set up a database, and wire the proxy middleware.

The WebAuthn and Second-Factor Story

Authelia supports several second-factor methods, and the README highlights security keys with FIDO2 and WebAuthn, including YubiKey. It also supports TOTP with authenticator apps and mobile push via Duo. Passwordless authentication with WebAuthn passkeys is listed as a feature. That breadth is useful because it lets you enforce different policies per rule. One rule might require only a password for an internal tool, while another requires a security key for admin panels. The portal UI shows the available 2FA methods, so users can self-select. The trade-off is that Duo push requires a Duo account and an API integration, which adds an external dependency. For a purely self-hosted setup, WebAuthn and TOTP are enough, but the push option is only there if you already use Duo.

Limitations and Failure Modes

The most obvious limitation is that Authelia is not an identity provider. It does not manage user lifecycles or provide a directory. You still need a user store, and the README does not detail which backends are supported beyond the general mention of a remote database. The second limitation is the dependency on external infrastructure. High availability requires Redis and a remote database. If those go down, Authelia cannot evaluate sessions, and the proxy will block requests. That is a fail-closed design, which is safe but can lock you out. The third limitation is configuration complexity. The README lists many integration points, but each proxy has its own middleware syntax. Traefik uses ForwardAuth, Caddy uses forward_auth, and nginx uses auth_request. Getting the headers and redirects right is a known pain point. The docker compose bundles reduce that friction, but they still require customization. Finally, the OpenID Connect beta status means you should not assume every OIDC feature is stable.

Alternatives and How They Differ

The most direct alternative is oauth2-proxy, a lightweight reverse proxy authenticator that also works with forward_auth and auth_request. The difference is that oauth2-proxy delegates authentication to an external OIDC provider like Google or Dex; it does not have its own user store or second-factor methods. Authelia is self-contained, with its own password database, WebAuthn, and TOTP. If you already have an identity provider, oauth2-proxy is simpler. If you want a standalone SSO portal with built-in 2FA, Authelia fits. Another alternative is Keycloak, which is a full identity and access management server. Keycloak has its own user federation, social login, and a broader OIDC implementation. But Keycloak is heavier, requires its own database, and does not directly integrate with reverse proxies the way Authelia does. You would put Keycloak behind a proxy and use its middleware or a separate component. Authelia's advantage is that the proxy integration is first-class.

Maintenance and Licensing

Authelia is licensed under Apache-2.0, which permits commercial use, modification, and distribution with attribution. There are no copyleft obligations, so you can embed it in a proprietary deployment. Maintenance cost is moderate. The project is actively developed, with three releases in the v4.39.x line within about six weeks as of May 2026. That cadence means you should expect regular updates, and you should track the release notes for breaking changes. The configuration format is YAML, and it is stable enough that the README does not mention frequent migration pain, but the OIDC beta status implies possible changes. The Helm chart is beta, so expect changes there. You will also need to keep your proxy middleware configuration in sync with Authelia's session and cookie settings. The documentation site is the canonical reference, and the README links to it for every feature. For upgrades, the release feed on GitHub is the practical source of truth.

Editorial conclusion

Adopt Authelia if you run a reverse proxy like nginx, Traefik, or Caddy and need a self-hosted, policy-driven SSO portal with WebAuthn, TOTP, and Duo push. Skip it if you want a turnkey identity provider or if your team cannot commit to maintaining a separate configuration file and a remote database plus Redis for high availability. Before production, verify your proxy's forward_auth integration, test the OpenID Connect beta with your client, and confirm the Helm chart's beta status matches your Kubernetes risk tolerance. The OpenID Certified mark is real, but the roadmap still labels OIDC as beta, so treat it accordingly.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes