What an SSO layer is actually doing

A self-hosted identity provider (IdP) sits in front of your apps and becomes the one place a login actually happens. Apps that support it hand off authentication to the IdP instead of managing their own user database, using a standard protocol, usually OpenID Connect (OIDC) or SAML, sometimes plain LDAP for older software that doesn’t speak either. Apps that don’t natively support any of those can often still sit behind a “forward auth” layer at the reverse proxy, where the proxy checks with the IdP before letting a request through at all, which works even for apps that have zero built-in auth-delegation support.

What you get out of that: one password (ideally behind 2FA) instead of many, one place to disable an account and have it actually lock out everything at once, one login flow to actually harden well instead of hardening five weaker ones, and often single sign-on itself, log in once and move between apps without re-authenticating.

Authentik vs Authelia: the real difference

Both are solid, both are widely used in the self-hosted world, and the comparisons that just list feature checkboxes miss the part that actually matters for picking one.

Authelia is a forward-auth companion. It doesn’t want to be your app, it wants to sit next to your reverse proxy (Nginx, Traefik, Caddy) and answer one question over and over: is this request authenticated, yes or no. Configuration is file-based (YAML), which fits a GitOps-style, config-as-code workflow well, and it’s genuinely lightweight, low resource footprint, simple mental model. Where it’s weaker: it doesn’t have a real admin UI or user-management dashboard built in, user accounts typically live in a flat file or an LDAP backend you point it at, and OIDC provider support (letting Authelia be the actual OIDC issuer for apps that want that, not just forward-auth) is comparatively newer and less mature than Authentik’s.

Authentik is a full identity platform. It has a real admin web UI, first-class OIDC/SAML/LDAP provider support (it can genuinely act as a proper OIDC issuer for any app that wants one, not just forward-auth), built-in user self-service (password resets, profile management), and a flow-based system for building custom login/enrollment logic without writing code. The cost is complexity and footprint, it’s a heavier stack (runs on Postgres and Redis under the hood, not a single lightweight binary), and there’s more surface area to configure than Authelia’s narrower scope.

Picking between them

If your setup is a handful of self-hosted apps behind a reverse proxy and what you actually want is “block anyone who isn’t authenticated from reaching these,” Authelia does that job with less overhead and a simpler config file you can keep in version control. If you want a real identity platform, one place to manage users with a UI instead of hand-editing YAML, proper OIDC issuance for apps that specifically integrate with an identity provider (Grafana, Immich, and a growing list of self-hosted apps have native OIDC support now, not just forward-auth), and you don’t mind the extra Postgres/Redis dependency, Authentik is the more capable long-term choice.

A rough rule that holds up in practice: under about 5-8 self-hosted apps, mostly behind a reverse proxy, Authelia’s simplicity wins. Past that, especially once you’ve got apps with native OIDC support you want to actually use rather than just gate at the proxy, Authentik’s platform approach starts paying for its extra weight.

What forward auth actually protects, and what it doesn’t

It’s worth being precise about what an SSO/forward-auth layer secures. It protects the front door, the HTTP request has to clear authentication before the app behind it ever sees it. What it doesn’t do on its own: patch vulnerabilities inside the app itself, protect anything reachable by a path that bypasses the proxy (a service exposed directly on a port, or an app with its own separate login the proxy isn’t gating), or protect data already exposed through a misconfigured API endpoint the auth layer wasn’t told to check. Treat it as a strong first layer, not the entire security model, keep apps patched and don’t expose ports directly around the proxy just because “the SSO layer covers it.”

2FA, and why it’s not optional here

Centralizing authentication into one IdP means a compromised IdP account is now a skeleton key for everything behind it, which raises the stakes on that one login considerably. Both Authentik and Authelia support TOTP (authenticator-app) 2FA, and both support WebAuthn/FIDO2 hardware keys for an even stronger option. Turn 2FA on for the IdP account itself at minimum, even if you don’t bother enforcing it app-by-app, since that one account is now the thing guarding everything else.

Migration is incremental, not all-or-nothing

You don’t need to convert every app at once. A sane rollout: stand up the IdP, put it in forward-auth mode in front of one or two lower-stakes apps first (a dashboard, a read-only monitoring tool), confirm the login flow and session handling behave the way you expect, then work through the rest of your stack one app at a time. Apps with native OIDC support (if you went with Authentik) can be switched to true SSO as you get to them; everything else stays behind forward auth indefinitely, which is a perfectly fine permanent state, not just a stepping stone.

Bottom line

Once you’re running more than a handful of self-hosted apps, a shared login you manage in one place beats a pile of app-specific accounts you’re not actually tracking. Authelia is the lighter, config-file-driven option built specifically for forward-auth in front of a reverse proxy, a strong default if that’s all you need. Authentik is the fuller identity platform, worth the extra weight once you want real OIDC issuance, a proper admin UI, or you’re past the point where hand-editing a flat config file scales. Either way, turn on 2FA for the IdP account itself before anything else, since it’s now the one login that matters most.