Authelia

Authelia is an authentication server that sits next to your reverse proxy. Even if a self-hosted web app has no login of its own, Authelia can put a login portal and multi-factor authentication in front of it.

This review is for people who run web apps at home or at work and want to protect the way in. After reading it, you can do the following:

• Explain how a reverse proxy and Authelia work together
• Start Authelia on your own Linux machine with the official Docker Compose bundle
• Know which settings to revisit before you use it in production

##What Authelia is

Authelia is open source software released under the Apache License 2.0. According to the official repository, you can run it as a container on Docker or Kubernetes, or install it from a static binary, a .deb package, APT, the AUR, or FreeBSD Ports. A Helm chart (beta) is available for Kubernetes.

##How it works

The reverse proxy asks Authelia whether each incoming request may pass before forwarding it. A first-time visitor has no session cookie, so Authelia has the proxy redirect them to its own login portal. After a successful login, the user gets a session cookie that is valid for all subdomains of the protected domain. On the next visit, the proxy passes that cookie to Authelia, and if Authelia can verify it, the request goes through. Authelia never connects to the application backends. It only sees the parts of a request that relate to authentication, such as the Authorization header. Because of this, the protected service can be REST, GraphQL, or anything else on top of HTTP.

##What Authelia can do

The official README and configuration docs list these main features:

• Second factors: FIDO2 WebAuthn security keys (such as a YubiKey), time-based one-time passwords (TOTP) from an authenticator app, and mobile push notifications through Duo
• Passwordless login: Sign in with WebAuthn (passkeys).
• Fine-grained access control: Write rules that match on subdomain, user, group, request URI, request method, and network, then apply bypass, one_factor, two_factor, or deny.
• OpenID Connect 1.0 / OAuth 2.0: Authelia can act as an identity provider. The README says it is OpenID Certified, while the official roadmap still treats the feature as beta. The access control rules do not apply to OpenID Connect.
• Regulation: After repeated failed username and password attempts, Authelia temporarily bans the account or the client IP. The defaults ban for 5 minutes after 3 failures within 2 minutes.
• Password reset: Users can reset a password after verifying their identity by email.

##Supported reverse proxies

The official support matrix lists these proxies with integration guides: Traefik, Caddy, Envoy, NGINX, NGINX Proxy Manager, SWAG, HAProxy, and Skipper. Traefik 1.x is listed as legacy. Check the official Supported Proxies page for the details.

##Try it safely with the local bundle

The project provides a “local” bundle for testing without worrying about configuration. It is meant for servers that are not exposed to the internet. Domains go in your hosts file, and it uses self-signed certificates. Try it on your own Linux desktop or a test VM.

1. Install Docker and Docker Compose.

2. Clone the repository and check out the latest release.

   git clone https://github.com/authelia/authelia.git
   cd authelia
   git checkout $(git describe --tags `git rev-list --tags --max-count=1`)

3. Move to the local bundle folder and run the setup script. It uses sudo to edit /etc/hosts.

   cd examples/compose/local
   ./setup.sh

4. Open these three URLs in your browser and compare them (example.com is replaced by the domain you entered in step 3). Accept the self-signed certificate warning on each one.

To register a second-factor device, you open a link from a confirmation email. The demo does not send real email. It writes the message to ./authelia/notification.txt instead.

##What to get right in production

• HTTPS is required. The docs say Authelia must be served over https, even for testing. Because it relies on a cookie, every protected app must also use https and wss.
• Write the configuration first. The official Get started guide names jwt_secret, authentication_backend (LDAP or a YAML file), storage, session, notifier, and access_control as the sections to decide up front. The access control docs recommend setting default_policy to deny.
• Protect the storage encryption key. storage.encryption_key encrypts sensitive values in the database. The minimum is 20 characters, but a random alphanumeric string of 64 or more characters is strongly recommended.
• Pass secrets as files. The recommended way to supply values such as jwt_secret and the session secret is an environment variable ending in _FILE, such as AUTHELIA_JWT_SECRET_FILE. If you also set the same value another way, Authelia will not start.
• Choose production backends. The docs recommend SQLite3 for testing and lite deployments, PostgreSQL for production, Redis for sessions, and SMTP for notifications.
• Change the bundle defaults. The lite bundle’s users_database.yml contains a user whose default password is authelia. Change it before you go public.
• Do not place Authelia in front of someone else’s service or test it on sites you have no permission to use.

##How it differs from Keycloak

Keycloak manages users and apps from an admin console and supports SAML 2.0 in addition to OpenID Connect and OAuth 2.0. Authelia focuses on guarding the entrance together with a reverse proxy. You configure it in files, and it reads users from LDAP or a YAML file.

##Read next

• cd ../keycloakKeycloakAn identity and access management server that also handles user management and identity brokering
• cat ~/guides/lab-setup.mdSetting up a safe lab