Single sign-on for self-hosters: the honest state of it

Single sign-on in a self-hosted stack is not one technology. It is three, they behave completely differently under failure, and the marketing language treats them as interchangeable. Getting this wrong produces the two outcomes people actually report: logging in twice to everything, or an unauthenticated hole they did not know they made.

The three mechanisms, and what each one really gives you#

Forward auth: gates the request, does not log you in#

Your reverse proxy intercepts the request and asks an auth server whether this session is permitted. Authelia serves /api/authz/forward-auth for Traefik, Caddy and HAProxy, /api/authz/auth-request for nginx and /api/authz/ext-authz for Envoy. If the answer is yes, the request continues. If no, you are redirected to a login portal.

What this buys you: an app with no authentication of its own becomes unreachable to strangers, with two-factor in front of it. That is real and valuable.

What it does not buy you: the app still does not know who you are. Unless it reads Remote-User and Remote-Groups, you authenticate at the portal, pass, and then meet its own login form. Two logins.

The second problem is worse. Forward auth is all-or-nothing per path, so anything that is not a browser needs an exception: /api/ for a mobile app, /remote.php/dav for Nextcloud desktop clients, entire subdomains for Jellyfin on a TV. Every policy: bypass you write is an unauthenticated hole, and Authelia's access control rules are ordered with first match winning, so one bypass placed too high silently disables two-factor for everything below it. Audit the whole rule list, not the rule you just added.

There is also a boring blocker that stops people on day one. The session cookie must be set on a domain that is a parent of every protected app, and browsers enforce the Public Suffix List, so you cannot share a cookie between example.duckdns.org and example-auth.duckdns.org. Forward auth requires a registrable domain you own.

Trusted header auth: logs you in, trusts anything#

The proxy authenticates you and injects a header. The application reads it and treats the value as a logged-in identity, creating the account if it does not exist. Navidrome, Frigate and Firefly III all work this way.

This solves the double-login problem completely. It also means the application's entire security model is "I believe whatever the last hop told me". If anything can reach that application other than your proxy, then a single request settles it:

curl -H 'Remote-User: admin' http://10.0.0.20:4533/

Another container on the same Docker network can do that. So can any LAN device, if you published the port. The mitigation is not a setting inside the app, it is network topology: put the app on an internal Docker network with the proxy, publish nothing, and have the app refuse connections that did not come from the proxy's address.

Header auth is right for exactly one situation: an app whose network path you control completely, with no OIDC support, where a double login is unacceptable. It is not a default.

Native OIDC: the only one that ends as one identity#

The application redirects you to your provider, gets a signed ID token back, and matches or creates its own user record from the claims. You log in once. Group claims can drive roles. It survives native clients, because the client does the same redirect. It is the only mechanism that produces the thing people mean when they say single sign-on.

The cost is that the application has to support it, which is where the subject falls apart.

The gap, measured#

Of the 90 profiled tools that have user accounts at all, 50.0 percent ship native OIDC and 31.1 percent have nothing you can connect an identity provider to: local accounts only, or a proxy in front and nothing else. Another slice is LDAP-only or depends on a third-party plugin whose maintenance you do not control. Jellyfin's OIDC plugin repository was archived by its original author in May 2026 and is now carried by a community fork, which is a good illustration of what "supported" means in this category.

Read that table as an architecture document, not a scoreboard. Every row that is not oidc-native is a decision: forward auth and two logins, a trusted header and a network constraint, or a local account outside your identity system. There is no fourth option. The full analysis is in The single sign-on gap.

What to run at home#

For a household, the winning stack is the smallest one that covers your actual app list.

If every app you run speaks OIDC, use Pocket ID. It is a single Go binary, roughly 30 MB, passkey-only, and it passed the OpenID Foundation conformance suite in 2026. Setup is one container, one volume, APP_URL set to the exact external HTTPS URL and an ENCRYPTION_KEY from openssl rand -base64 32. It does nothing for apps without OIDC, and that limitation is the product rather than a gap.

Two things to know before you commit. WebAuthn credentials are bound to the relying party ID derived from APP_URL, so moving from id.home.lan to id.example.com invalidates every passkey your users registered. And WebAuthn requires a secure context, so a plain HTTP LAN deployment cannot register a credential at all. Decide the final domain and put a real certificate in front before you invite anyone. Reverse proxy and TLS covers that half.

If some of your apps have no auth at all, use Authelia plus your existing reverse proxy, and add LLDAP behind it if you want one password across the apps that only speak LDAP. Authelia at 35 MB plus LLDAP at 15 MB is a 50 MB identity layer, which is remarkable value. Be clear about what you are getting: forward auth for the no-auth apps, and an OIDC provider that the project itself still labels beta (Beta 8, targeted at 4.40.0) and that has shipped breaking changes inside minor releases.

Do not run authentik or Keycloak for a household. Both are excellent and both are the wrong size. authentik documents a 2 CPU core and 2 GB RAM minimum and spends roughly a gigabyte idle across three containers. Keycloak's container guide suggests 2 GB for the JVM alone. If your requirement is one OIDC issuer for six apps, that is a tenth of the memory and a hundredth of the concepts away.

What to run for a small team#

Here the answer flips, because the requirements change from "one login for my family" to "onboarding, offboarding, an audit trail and one stubborn vendor app that only speaks SAML".

Run authentik. It is the only option in this category that covers all four integration styles in one product: native OIDC, SAML, an LDAP outpost for apps that speak nothing else, and a proxy provider for apps with no auth at all. The gigabyte of RAM is a rounding error on a business server, and one admin UI showing who logged into what is worth real money when someone leaves.

Two operational notes. Since 2025.10 Redis is gone, with caching and sessions moved into PostgreSQL: budget about 50 percent more database connections and clear the orphaned container on upgrade. Since 2026.8 the server ignores X-Forwarded-* headers unless the connection comes from a network in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS. Set it before you pull the tag, or every login appears to come from your reverse proxy.

Choose Keycloak instead when you need realms as genuine tenant separation, token exchange, fine-grained authorization policies, or something an auditor already recognizes. Accept the cost: every version migrates the schema on first start with no reverse migration, so a rollback means restoring PostgreSQL rather than changing the image tag. And never run start-dev as a deployment: it uses a dev-file H2 database inside the container, there is no supported migration from it to PostgreSQL, and a docker compose down -v takes your realm with it. Keycloak vs authentik goes deeper on that fork in the road.

The account-linking trap#

This is the failure that catches almost everybody, and it happens on the day you switch a working app to OIDC.

The app already has a local user, alice, with three years of history. Alice logs in through your provider for the first time. The app receives a token with subject f47ac10b-... and email alice@example.com, finds no user matching that subject, and creates a second account. Alice is now looking at an empty library, an empty document list or a dashboard with no dashboards, and her real data belongs to an account she can no longer reach because you disabled password login an hour ago.

How different apps behave varies and you must check yours before you flip the switch:

• Some match on the email claim and link automatically. Convenient, and also an account takeover path if your provider does not verify email addresses.
• Some match on preferred username. Some match only on the OIDC subject and will never link an existing account without a manual database edit.
• Some, including Immich, leave local password login enabled after you configure OIDC until you disable it in admin settings, which gives you a window to test.

The safe procedure:

1. Configure OIDC but leave local login enabled.
2. Make the identity provider issue the exact email and username the local account already has.
3. Log in through OIDC as a test user first and confirm you land on the existing account with its data, not a fresh one.
4. Only then disable local password login, and only after you have a database backup you have restored once.

Do this in the wrong order across ten apps and you will spend a weekend merging users by hand in ten schemas.

The disaster case: your IdP is down#

Every app behind your identity provider is now inaccessible, and that set very likely includes the admin interface you would use to fix it. Put your proxy dashboard, container manager and monitoring behind the same forward auth and you have locked yourself out of the tools for diagnosing the lockout.

It gets more circular than that. If the provider is unreachable because DNS is broken and your DNS server's admin UI sits behind the provider, you are editing hosts files.

Write these down on installation day, not during the incident:

• Keep one route in that does not depend on identity. SSH with a key, or a WireGuard tunnel. Never gate SSH behind your web SSO.
• Keep a local admin account on every critical app, even after you enable OIDC. Yes, this weakens the "one identity" story. It is the correct trade.
• Know the recovery command. authentik: docker compose run --rm server create_recovery_key 10 akadmin, which prints a link valid for ten minutes. Pocket ID: an admin-issued one-time access link, which means you need a second admin. Keycloak: a bootstrap admin via environment variables against the database.
• Have a second admin with credentials on different hardware. For Pocket ID this is not optional: there is no password fallback, so if the only admin loses every enrolled passkey you are editing SQLite by hand.
• Do not put the identity provider behind its own forward auth. People do this. It works until it does not.
• Back up the encryption key separately from the database. Authelia's storage.encryption_key, authentik's AUTHENTIK_SECRET_KEY, Pocket ID's ENCRYPTION_KEY and LLDAP's LLDAP_KEY_SEED all live outside their databases. Restore a dump with a different key and every TOTP secret, passkey and stored credential in it is garbage.

What to do next#

Sort your actual app list into three piles using the table above: native OIDC, LDAP or plugin, and nothing. If the third pile is small, Pocket ID is your answer and an evening is enough. If it is large, you need forward auth, which means Authelia and a real domain, so read Reverse proxy and TLS first. Either way, create the break-glass account before you enable anything, and check A security baseline for a home server for the rest of the perimeter.