Building a Unified Auth Layer: Authelia's Multi-Protocol Juggling Act

Authelia SSO: When One Auth Is Not Enough

The borisovai-admin project needed serious authentication overhaul. The challenge wasn’t just protecting endpoints—it was creating a unified identity system that could speak multiple authentication languages: ForwardAuth for legacy services, OIDC for modern apps, and session-based auth for fallback scenarios. I had to build this without breaking the existing infrastructure running n8n, Mailu, and the Management UI.

The problem was elegantly simple in theory, brutal in practice. Each service had its own auth expectations. Traefik wanted middleware that could intercept requests before they hit the app layer. The Management UI needed OIDC support through express-openid-connect. Older services expected ForwardAuth headers. And everything had to converge on a single DNS endpoint: auth.borisovai.ru.

I started by writing install-authelia.sh—a complete bootstrapping script that handled binary installation, secret generation, systemd service setup, and DNS configuration. This wasn’t just about deployment; it was about making the entire system repeatable and maintainable. Next came the critical piece: authelia.yml, which I configured as both a ForwardAuth middleware and a router pointing the /tech path to the Management UI. This dual role became the architectural linchpin.

The real complexity emerged in server.js, where I implemented OIDC dual-mode authentication. The pattern was elegant: Bearer token checks first, fallback to OIDC token validation through express-openid-connect, and finally session-based auth as the ultimate fallback. It meant requests could be authenticated through three different mechanisms, transparently to the user. The logout flow had to support OIDC redirect semantics across five HTML pages—ensuring that logging out didn’t just clear sessions but also hit the identity provider’s logout endpoints.

Here’s what made this particularly interesting: Authelia’s ForwardAuth protocol doesn’t just pass authentication status; it injects special headers into proxied requests. This header-based communication pattern is how Traefik, Mailu, and n8n receive identity information without understanding OIDC or session mechanics. I had to ensure authelia@file was correctly injected into the Traefik router definitions in management-ui.yml and n8n.yml.

The configure-traefik.sh script became the glue—generating clean authelia.yml configurations and injecting the ForwardAuth middleware into service templates. Meanwhile, install-management-ui.sh added auto-detection of Authelia’s presence and automatically populated the OIDC configuration into config.json. This meant the Management UI could discover its auth provider dynamically.

The whole system shipped as part of install-all.sh, where INSTALL_AUTHELIA became step 7.5/10—positioned right before applications that depend on it. Testing this required validating that a request through Traefik with ForwardAuth headers, an OIDC bearer token, and a session cookie would all authenticate correctly under different scenarios.

Key lesson: Building a unified auth system isn’t about choosing one pattern—it’s about creating translation layers that let legacy and modern systems coexist peacefully. ForwardAuth and OIDC aren’t competing; they’re complementary when you design the handoff correctly.

😄 My boss asked why Authelia config took so long. I said it was because I had to authenticate with three different protocols just to convince Git that I was the right person to commit the changes.