Learn Authelia - History, Background & Why You Need Authelia

#Introduction

After episode 0 made sure the environment is ready — basic reverse proxy and forward authentication skills, Docker Compose installed, and the lab topology designed — in this episode we step back for a moment to answer the most decisive question: why do we need Authelia?

This question isn't just historical trivia. Understanding Authelia's background answers three practical questions: (1) what exactly is the problem with "many applications, many login systems" that we've been accepting as normal, (2) why the existing solutions — basic auth, oauth2-proxy, Authentik, Keycloak — don't always fit, and (3) when Authelia is the right choice and when it isn't. Like understanding the history of a technology, understanding Authelia's background means you can not only install it, but know why it exists.

#The Problem: Many Applications, Many Entrances

Imagine your house has ten doors, and each door has a different key. The same guest has to carry ten different keys, and you have to remember ten different rules about who may pass through which door. That's the state of the typical self-hosted server:

1. Password fatigue. One person remembers passwords for Grafana, Nextcloud, Portainer, Jellyfin, and dozens of other applications. The result: passwords are reused, written on sticky notes, or chosen to be the easiest to guess.
2. Inconsistent policies. One application requires a strong password, another accepts 123456. There's no shared standard.
3. No single point of audit. If an account is compromised, there's no single place to see all login activity — each application logs it on its own, in its own format.
4. Security depends on the weakest application. One application without MFA support becomes the weakest entry point into the whole network.

Authelia was born as an answer to this chaos: one entrance, one policy, one audit trail, and one place to enforce MFA.

#The Authentication Landscape Before Authelia

#Per-Application Authentication

The most traditional approach: every application has its own login system, its own user database, and its own policies. For one to three applications, this still makes sense. Beyond that, the management burden grows faster than its value.

#Basic Auth in the Reverse Proxy

The next step people often try: the reverse proxy (for example NGINX) adds a simple login layer with the auth_basic directive:

location / {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

The problems: credentials are sent as plain text (only base64-encoded, not encrypted — safe only over HTTPS), there's no MFA support, no user management, and all users typically share the same single username/password.

#Forward Authentication

A more modern pattern: the proxy "hands over" the authentication decision to an external service. Authelia is one implementation of forward authentication — it checks the session, redirects to the login portal when necessary, then tells the proxy whether the request may be forwarded. This is the pattern that forms Authelia's backbone and that we'll dissect in episode 2.

#The Rise of the SSO Need in the Self-Hosted World

The more services you homelab, the stronger the need for Single Sign-On (SSO): log in once, all applications open. SSO isn't an enterprise luxury — for the owner of one VPS with five applications, SSO is the humanly sensible way to manage identity.

#The Birth of Authelia

Authelia was born in 2016 as a community-driven open-source project, licensed under Apache 2.0. Its vision from the start was simple yet firm: to be a lightweight authentication server focused on forward authentication — one thing done very well — rather than a giant platform trying to do everything.

Because it's written in Go, Authelia compiles into a single binary: it's lightweight to deploy, has low memory consumption, and there's no runtime to manage. This design came from the real needs of the self-hosting community: a solution that fits on small servers, is easy to deploy, and integrates seamlessly with existing reverse proxies.

#Authelia's Key Features

• SSO portal — one login page for all protected applications.
• Complete MFA — TOTP (Google Authenticator, Authy), WebAuthn/FIDO2 (YubiKey, Touch ID), and Duo Push.
• Access control rules — granular policies based on domain, path, user, group, and network (bypass, one_factor, two_factor, deny policies).
• Identity proxying — user identity is forwarded to applications via HTTP headers (Remote-User, Remote-Groups, and others), so even applications without their own login system can recognize users.
• Brute force protection (regulation) — rate limiting failed login attempts by IP and user.
• OIDC provider — Authelia can also act as an Identity Provider for modern applications that support OpenID Connect (covered in phase 5 of this series).

#Authelia vs the Alternatives

The essence of the comparison: Authentik and Keycloak are giant identity platforms — great, but they require significant resources and learning time. Authelia is intentionally narrow: it handles forward authentication, SSO, and MFA very well, and does almost nothing else. For homelabs and small businesses, narrow isn't a weakness — it's a strength.

#Why Choose Authelia

• Lightweight and efficient — written in Go, single binary, low RAM usage; comfortable on a 1–2 GB VPS.
• Easy to deploy — official Docker image authelia/authelia and a single binary.
• Designed for reverse proxies — NGINX, Traefik, Caddy, and HAProxy integrations are first-class citizens.
• Strong security — MFA, rule-based access control, and brute force protection.
• Privacy-first — no telemetry, user data is stored in storage you own.
• No vendor lock-in — open source under Apache 2.0, simple file-based configuration, easy to migrate away.
• Active community — good documentation, steady development.

#The Right Use Cases

Authelia is a great fit for:

• Homelab SSO — protecting your entire home server behind a single login portal.
• Self-hosted services — Grafana, Nextcloud, Portainer, and other applications you don't want left "naked" without their own authentication.
• Small business internal tools — team access control without enterprise IdP license costs.
• Development environments — protecting staging and preview environments.
• IoT devices and home automation — wrapping dashboards that usually lack strong logins.

#Closing

In episode 1 we've understood the root problem Authelia solves: the chaos of many login doors — password fatigue, inconsistent policies, and security that depends on the weakest application. We traced the evolution of solutions from per-application authentication, basic auth at the proxy, up to the forward authentication pattern, and saw the birth of Authelia in 2016 as a lightweight forward authentication server focused on SSO, MFA, and access control — written in Go, licensed Apache 2.0, no telemetry. We also compared it honestly with oauth2-proxy, Authentik, and Keycloak.

Key takeaways:

• The real problem is many applications with many unmanaged login systems.
• Authelia is a specialist, not an all-in-one — and being narrow is exactly its strength.
• For homelabs and small businesses, Authelia wins because it's lightweight, easy, and focused.
• The best security is the one that's consistent — one door, one policy, one audit trail.

In the next episode, episode 2, we'll dissect Authelia's architecture and core concepts: how the Authelia server, Redis, the user database, and the reverse proxy work together, the journey of a single request from the browser back with a session cookie, and key terms such as access control and policy. See you in episode 2!