Lion Cipher Lab
Add single sign-on and 2FA to your self-hosted apps with Authelia (forward auth)
- Cyber / Security Engineer
- Intermediate
- ~75 min
- Free · no account required
Why it matters
The moment you self-host anything — a dashboard, a media server, an admin panel, a home lab tool — you inherit an authentication problem. Many of these apps have weak login pages, shared passwords, or literally no auth at all, and each one is a separate door an attacker can rattle. Forward auth flips that: you put ONE authentication portal in front of everything, so you configure login, lockout, and 2FA in a single place and every app behind the proxy inherits it. This is exactly how mature teams protect internal tooling, and it is the on-ramp to real single sign-on (SSO). Learning it locally…
What you'll learn
- what forward auth (auth request) is and how a proxy delegates login to an auth server
- the difference between forward auth, per-app login, and full OIDC single sign-on
- standing up Authelia + Caddy + a backend app with Docker Compose
- generating an Argon2 password hash for a users database
- writing Authelia access_control rules (bypass vs one_factor vs two_factor)
- wiring Caddy's forward_auth directive to Authelia
- enrolling TOTP 2FA with an authenticator app
- proving protection with curl (no session vs valid session)
- recognising the forwarded-identity trust-boundary trap
Steps in this lab
- What forward auth is — and how it differs from per-app login and full SSO
- Get Docker, a terminal, and a project folder ready
- Lay out the stack: Authelia + Caddy + a dummy app
- Generate a hashed password for your user
- Write Authelia's users file and main configuration
- Point Caddy at Authelia with the forward_auth directive
- Start the stack and log in through the portal
- Prove it: no session is blocked, a valid session gets 200
- The judgment: when to reach for this, the trap, and when NOT to