Double Authentication Blues: When Security Layers Collide

Untangling the Auth Maze: When Two Security Layers Fight Back

The Management UI for borisovai-admin was finally running, but something felt off. It started during testing—users would get redirected once, then redirected again, bouncing between authentication systems like a pinball. The task seemed simple on the surface: set up a proper admin interface with authentication. The reality? Two security mechanisms were stepping on each other’s toes, and I had to figure out which one to keep.

Here’s what was happening under the hood. The infrastructure was already protected by Traefik with ForwardAuth, delegating all authentication decisions to Authelia running at the edge. This is solid—it means every request hitting the admin endpoint gets validated at the proxy level before it even reaches the application. But then I added express-openid-connect (OIDC) directly into the Management UI itself, thinking it would provide additional security. Instead, it created a cascade: ForwardAuth would redirect to Authelia, users would complete two-factor authentication, and then the Management UI would immediately redirect them again to complete OIDC. Two separate auth flows were fighting for control.

The decision was straightforward once I understood the architecture: remove the redundant OIDC layer. Traefik’s ForwardAuth already handles the heavy lifting—validating sessions, enforcing 2FA through Authelia, and protecting the entire admin surface. Adding OIDC on top was security theater, not defense in depth. So I disabled express-openid-connect and fell back to a simpler authentication model: legacy session-based login handled directly by the Management UI itself, sitting safely behind Traefik’s protective barrier.

Now the flow is clean. Users hit https://admin.borisovai.tech, Traefik intercepts the request, ForwardAuth redirects them to Authelia if their session is invalid, they complete 2FA, and then—crucially, only then—they’re allowed to access the Management UI login page where standard credentials do the final validation.

But while testing this, I discovered another issue lurking in the DNS layer. The .ru domain records for admin.borisovai.ru and auth.borisovai.ru were never added to the registrar’s control panel at IHC. Let’s Encrypt can’t issue SSL certificates without verifying DNS A-records, and Let’s Encrypt can’t verify what doesn’t exist. The fix requires adding those A-records pointing to 144.91.108.139 through the IHC panel—a reminder that infrastructure security lives in multiple layers, and each one matters.

This whole experience reinforced something important: sometimes security elegance means knowing what NOT to add. Every authentication layer you introduce is another surface for bugs, configuration conflicts, and user friction. The best security architecture is often the simplest one that still solves the problem. In this case, that meant trusting Traefik and Authelia to do their job, and letting the Management UI focus on what it does best.

// This line doesn't actually do anything, but the code stops working when I delete it.