The single sign-on gap

Of the 90 indexed tools that have user accounts, 45 support OpenID Connect natively, which is 50.0 percent. Counting official and de-facto plugins takes it to 51, or 56.7 percent. The remaining 28, 31.1 percent, have nothing to federate: local accounts, a single shared password, or no authentication at all and an instruction to put a proxy in front.

That last number is the one that decides your architecture. You do not get a unified login by picking a good identity provider. You get it by not running anything from the third group, which for most households is not a choice they are willing to make.

"Supports OIDC" is five different claims#

The phrase collapses five arrangements that deliver very different things. Sorting the index into them is most of the value here.

Native OIDC. The application is an OIDC relying party in its own code. You give it an issuer URL, a client ID and a secret, and it redirects to your provider. 45 tools are here. The good implementations also map claims to roles and let you turn off local login: Mealie has ALLOW_PASSWORD_LOGIN=false, Karakeep has DISABLE_PASSWORD_AUTH and OAUTH_AUTO_REDIRECT, Beszel has DISABLE_PASSWORD_AUTH. That is the full-fat version and it is what you should be shopping for.

Plugin OIDC. Six tools. The code is not in the core project, which means it has its own release cadence and its own bus factor. Jellyfin is the cautionary example: the LDAP plugin is official, the SSO plugin is not, and the 9p4 repository that hosted it was archived on 12 May 2026. A community fork carries it on, but if you configured the old manifest URL you simply stopped receiving updates, silently. Nextcloud is the better version of the same shape, where user_oidc is maintained in the app store but still has to survive every major upgrade.

LDAP only. Five tools, and this is where the language gets sloppiest. LDAP gives you one password everywhere. It does not give you one session. Every app still shows its own login form, you still type credentials into each one, and logging out of one logs you out of nothing else. LLDAP exists precisely to serve this group cheaply, at 15 MB idle and an ops load of 1 out of 5.

Trusted header auth. Six tools. The proxy authenticates you and injects a header such as Remote-User, and the app creates or looks up that account and logs you in. This genuinely feels like single sign-on. It is also a total compromise the moment anything can reach the application directly, because the header is just a header and anyone who can connect to the port can set it. Navidrome auto-creates users this way and the first one created becomes an admin, so an unprotected port 4533 is an admin account for whoever asks first. Every implementation ships a trust list: ND_REVERSEPROXYWHITELIST, Miniflux's TRUSTED_REVERSE_PROXY_NETWORKS, FreshRSS's trusted_sources. FreshRSS additionally auto-registers unknown users, which turns a permissive CIDR into open registration.

Forward auth only. Eight tools, and this is the category people miscount. Forward auth is a proxy decision: Caddy's forward_auth or a Traefik middleware asks Authelia whether this request may pass. If it may, the request goes through, and the application behind it has learned nothing about you and asks you to log in again. You have one authorization decision and two logins. It is worth doing for code-server, whose entire auth model is one shared password in a YAML file, and for Netdata, whose port 19999 dashboard has no login at all. It is not federation.

The recent arrivals, the retreats, and the never#

Three movements are visible in the data, and they point in different directions.

OIDC arrived recently in a cluster of infrastructure tools that spent years with a single admin password. Technitium DNS Server shipped OIDC with scope and group-to-role mapping in v15 in April 2026. Unraid added it to the WebGUI in 7.2 through its built-in API. wg-easy got OAuth and OIDC in 15.4.0 in August 2026. Kavita landed native OIDC in v0.8.8 with role mapping onto library access. Vaultwarden has had it since 1.35.0. If your mental model of self-hosted SSO is from 2023, it is out of date in your favor.

The retreats went the other way and cost people real work. PLANKA 2.2.0 removed OIDC to PLANKA Pro and deactivated every SSO-created user, because those accounts had no password to fall back on. Recovery is an admin setting a password for each one and reactivating them individually. MinIO removed LDAP and OIDC from the community build in the May 2025 release and moved them into the commercial product, in the same release that took away the console. Mattermost Team Edition lost GitLab SSO, its only method, in v11. Docmost gates SAML, OIDC and LDAP behind a Business tier at 6 dollars per seat per month with a ten seat minimum. n8n does the same under an Enterprise plan. Stalwart Community will act as an OIDC provider but will not accept logins from one without an Enterprise license.

And some will never have it, for structural reasons rather than neglect. Plex cannot federate because identity is plex.tv by design. Sonarr, Radarr and Prowlarr have forms login and an API key that bypasses it entirely for anything holding it, so the login is not really the credential. Pi-hole and AdGuard Home have one web password because they are resolvers, not multi-user applications. Nginx Proxy Manager has no plans for it in the v2 line. Syncthing, Zigbee2MQTT and Glance are all single-secret designs. Waiting for these is not a plan.

What to actually do with this distribution#

Run a small provider, not a large one. Given that 56.7 percent of the apps with accounts can consume OIDC, the provider's job is mostly issuing tokens, and the cheap options do that well. Pocket ID is 30 MB idle, ops load 1, passkey-only and OpenID Certified. Authelia is 35 MB and gives you forward auth in the same process, which matters because you will need it. authentik is a genuinely capable IdP and costs about 1 GB of RAM and an ops load of 4 out of 5; pick it when you actually need SAML, an LDAP outpost or upstream federation, not by default. Keycloak is 750 MB and an upgrade path with real cliffs in it. The head to head reading is Pocket ID vs Authelia and Authelia vs authentik.

Then accept the split. Federate everything that can federate. Put forward auth in front of the handful that cannot, and accept the second login there. Add LLDAP if you have two or three LDAP-only holdouts worth keeping. This is a three-container identity layer under 100 MB, and it is the honest answer for a household.

The network path matters as much as the config. Header auth and forward auth are both only as strong as the guarantee that the app is unreachable except through the proxy. That means not publishing the container port at all, putting the app on an internal Docker network with only the proxy attached, and remembering that published ports bypass UFW because Docker writes its own iptables chains. Reverse proxy and TLS covers the proxy side and A security baseline for a home server covers the host side.

One more failure mode worth designing against: Outline has no local accounts at all, ever. If your provider's certificate expires or its container fails to start, nobody can get into Outline to fix anything. A single provider is a single point of failure for your entire estate, so keep a break-glass path: a local admin account on the apps that allow one, and a tested restore of the provider's own database.

Next step#

Run your own list against the our methodology definitions and count how many of your apps land in the none and proxy-only rows of the table above. If the answer is more than three, your first move is not installing an identity provider, it is deciding which of those three you are willing to replace. Single sign-on for self-hosters walks the actual setup, and Stack planner will show you the identity load of a stack before you build it.