Category
Passwords, SSO and identity
There are only two ways to put one login in front of many services, and picking the wrong one is why people end up with a login page in front of a login page.
Everything here solves one problem, in one of two incompatible ways.
Forward auth puts a gate in front of the HTTP request. Your proxy asks the identity service "is this session allowed?" before the app sees the traffic. It works with any application, including ones with no concept of users, and it does not log you into anything: unless the app reads Remote-User and Remote-Groups headers, your users authenticate at the gate, pass, and meet a second login form.
Native OIDC logs you into the app itself: one session, one identity, no second form. It only works where the application implemented it, and that constraint decides your design.
Of the 90 tools here with user accounts, 50.0 percent have native OIDC and 31.1 percent have no external identity integration at all. Neither mechanism covers your stack alone, so most working setups run both.
The default: Pocket ID plus Vaultwarden#
For a household with five to fifteen services that mostly speak OIDC, run Pocket ID: a single Go binary, 30 MB idle, ops load 1, OpenID certified, passkey-only. It is the OIDC issuer and nothing else, which is why it costs a thirtieth of what a full identity platform does. Alongside it, Vaultwarden for the credentials that will never be federated: 40 MB, every Bitwarden paid-tier feature unlocked, and Bitwarden's own clients everywhere.
Two Pocket ID limits are load-bearing. Passkeys are welded to the hostname in APP_URL, so decide your final domain before you invite anyone. And WebAuthn needs a secure context, so a plain HTTP LAN address cannot register a credential: the login page renders, registration fails, and the browser error never mentions TLS.
Skip the default if either of these applies to you.
Half your apps have no login worth trusting. Pocket ID has no forward auth, no proxy provider and no header injection. Use Authelia: 35 MB, a 2FA portal in front of your proxy, an LDAP or YAML user source. Pair it with LLDAP (15 MB) for one place to change a password.
You need SAML, or an LDAP outpost, or all four integration styles at once. Then authentik, the only thing here covering native OIDC, SAML, LDAP and forward auth from one admin UI, for about a gigabyte idle and ops load 4. Keycloak is the alternative when an auditor needs to recognize the name, at 750 MB plus PostgreSQL and the hardest upgrade path here: each version migrates the schema on first start with no way back except restoring the dump.
The uncomfortable part#
"Supports OIDC" and "usable as single sign-on" are different claims, and README badges do not distinguish them. The pattern is always the same: the web UI federates and the native clients do not.
Jellyfin's SSO plugin covers the browser; the TV app still checks Jellyfin's own user table, and the original plugin repository was archived in May 2026. Navidrome's Subsonic apps authenticate at /rest with a Navidrome password, so every SSO user still needs one. Vaultwarden gained OIDC login in 1.35.0 and still requires a master password, because that password derives the vault key. Seerr's OIDC is a preview branch.
Plan for that split. It is not a temporary state of the ecosystem, it is what happens when a browser protocol meets applications with native clients.
The mistakes people actually make#
- Prototyping identity on a domain you will change. Pocket ID's passkeys and Authelia's session cookies are both domain-bound, and the Public Suffix List means
example.duckdns.orgcannot share a cookie with a sibling subdomain. Get a registrable domain first. - Running Authelia with the default session provider. In-memory sessions are the default, so every container restart signs out every user, including anyone mid-way through TOTP enrollment. The fix is Redis, and your one-container deployment is now two.
- Editing an authentication flow with no way back. In authentik, flows are editable objects: remove the wrong stage and nobody can log in,
akadminincluded. Write downdocker compose run --rm server create_recovery_key 10 akadminbefore you start. - Upgrading authentik without setting trusted proxy CIDRs. Since 2026.8, forwarded headers are ignored unless the source network is listed, so every login appears to come from your proxy and IP policies stop matching.
- Running Keycloak in dev mode for months.
start-devstores everything in an H2 file inside the container, there is no supported migration to PostgreSQL, anddocker compose down -vtakes the realm with it.
What to read next#
Single sign-on for self-hosters is the walkthrough, including which of your apps will never participate, and The single sign-on gap has the breakdown behind the numbers above. For the head-to-head calls: Authelia vs authentik, Pocket ID vs Authelia and Keycloak vs authentik. The gate lives at the proxy, so Reverse proxy and TLS and A security baseline for a home server are the companions here, and Replace LastPass or 1Password covers moving a vault off a hosted service.
Every identity tool we profile#
Sorted by operational load, lightest commitment first. Every row links to a full profile with the resource numbers, the upgrade traps and the restore path.
| Tool | Ops load | Idle RAM | Licence | Identity | Backup shape |
|---|---|---|---|---|---|
| LLDAP | 1, Set and forget | 15 MB | GPL-3.0 | LDAP only | SQLite backup |
| Pocket ID | 1, Set and forget | 30 MB | BSD-2-Clause | Native OIDC | SQLite backup |
| Vaultwarden | 2, Light | 40 MB | AGPL-3.0 | Native OIDC | SQLite backup |
| Authelia | 3, Moderate | 35 MB | Apache-2.0 | LDAP only | SQLite backup |
| Keycloak | 4, Heavy | 750 MB | Apache-2.0 | Native OIDC | Postgres dump |
| authentik | 4, Heavy | 1000 MB | MIT (core); authentik/enterprise/ under a separate Authentik Security license | Native OIDC | Postgres dump |
Profiles#
LLDAP
A tiny LDAP server for the apps that only speak LDAP
ops 1/5 · 30 MBPocket ID
Passkey-only OIDC provider in a single Go binary
ops 2/5 · 40 MBVaultwarden
Rust reimplementation of the Bitwarden server API, with the paid org features unlocked
ops 3/5 · 35 MBAuthelia
Forward-auth portal and 2FA gate for your reverse proxy, with a beta OIDC provider
ops 4/5 · 750 MBKeycloak
The reference open source IdP: every protocol is supported, and you administer all of it
ops 4/5 · 1000 MBauthentik
Full identity provider: OIDC, SAML, an LDAP outpost and forward auth, for about a gigabyte
Head to head in this category#
- Authelia vs authentikA 35 MB request gate against a 1 GB identity provider, and the difference between gating a request and logging someone in.
- Keycloak vs authentikEnterprise-grade protocol coverage against homelab-shaped ergonomics, and the hardest upgrade path in the category.
- Pocket ID vs AutheliaA passkey-only OIDC issuer against a general request gate, decided by what your applications can actually consume.
Leaving a cloud service in this category#
- Replace LastPass or 1PasswordWhy Bitwarden's free tier is the right answer for most people, and what Vaultwarden actually asks of you.
Guides for this category#
- Single sign-on for self-hosters: the honest state of itThree mechanisms, one of which actually works. Plus the account-linking trap and the lockout you have not planned for.
Questions#
What is the difference between an app supporting OIDC and being usable for single sign-on?
"Supports OIDC" means the web interface can redirect to your provider. Single sign-on means every way into that app respects it. Those come apart constantly. Jellyfin's OIDC plugin covers the web UI only: native clients on a TV still authenticate against Jellyfin's own user database. Navidrome's Subsonic clients hit /rest endpoints with their own password. Vaultwarden supports OIDC and still requires a master password, because that password derives the vault key and the provider cannot supply it. Check the mobile path before you count an app as covered.
How many self-hosted apps actually support SSO?
Of the 90 tools here that have user accounts, 50.0 percent have native OIDC login built in with no plugin, and 31.1 percent have no external identity integration at all: local accounts only, or nothing but a proxy in front. That second number is the one that decides your architecture. If a third of your stack can never speak OIDC, an OIDC-only provider covers two thirds of your logins and you still need a forward-auth gate or separate passwords for the rest.
Authelia or authentik?
Authelia if your requirement is a 2FA gate in front of apps that have no authentication of their own. It is 35 MB and one config file, and the forward-auth half has been dependable for years, though its OIDC provider is still labelled beta. authentik if you need SAML for one stubborn application, or an LDAP outpost, or a proxy provider, all from one admin UI. That completeness costs about a gigabyte idle across its containers, and the docs ask for 2 CPU cores and 2 GB before anyone logs in.
Do I need an identity provider at all?
If you are the only user and everything sits behind a VPN, no. A password manager plus unique passwords is a complete answer, and it is the one most single-operator homelabs should stop at. An identity provider earns its keep at the point where other people have accounts, where you would otherwise be resetting five passwords for one person, or where you want to revoke someone's access to everything in one action. Below that, you are adding a service whose failure locks you out of the services it protects.
Will forward auth break my phone apps?
Yes, unless you write exceptions, and the exceptions are where the protection leaks. Forward auth gates the HTTP request, so anything that is not a browser fails: mobile clients, WebDAV, API tokens, a TV app. The fix is a policy: bypass rule for /api/, /remote.php/dav, or a whole subdomain, and every one of those is an unauthenticated hole. Rules are first-match-wins, so one placed too high silently disables two-factor for everything below it. Audit the whole list, not just the rule you added last.
What happens when my identity provider goes down?
Everything behind it stops. That is the honest cost of consolidating logins, and it is why the provider should be the least exciting service you run, on the machine you touch least. Outline is the extreme case: it has no local accounts at all, so an expired certificate on your provider locks you out of your own wiki. Keep local login enabled on at least one admin account where the app allows it, keep a recovery path written down (authentik's create_recovery_key, Pocket ID's one-time access link), and test it before you need it.
Can I lose my accounts by restoring a backup?
Yes, if you restore the database without the key that encrypts it. Authelia encrypts TOTP secrets and WebAuthn credentials with storage.encryption_key from the config file, so a dump restored under a different key means every user re-enrolls. LLDAP's key seed does the same to stored passwords, including the admin's. Pocket ID's passkeys are bound to the hostname in APP_URL, so changing domain invalidates every credential at once. Store those values with the backup set, in a password manager, not only on the host.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.