An XDA writer recently walked through the four things they did to secure a Plex server before exposing it to the internet: enforce TLS, stop advertising port 32400 straight through the router, put the thing behind a reverse proxy, and turn on two-factor for the account. All sensible. All incomplete. The reverse proxy terminates TLS and routes hostnames, and then it hands the request to the application, which is left to decide on its own whether the person on the other end should be there. Every service ends up with its own login page, its own password rules, and its own idea of what “logged out” means.
That gap is what the best apps for self-hosted SSO fill. One identity provider sits behind the reverse proxy, every service defers to it, MFA gets enforced once for everything, and removing somebody’s access is a single toggle rather than a tour of twelve admin panels. We looked at 8 options that are actively developed and running in real home labs today, from full identity providers with their own database to a single container that answers one yes-or-no question per request.
What to look for in a self-hosted SSO app
- Protocol coverage. If your apps speak OIDC or SAML natively, an identity provider is the clean answer. If half of them speak nothing at all, you need forward auth as well, not instead.
- Whether it owns a user store. Some of these hold accounts, groups, and password hashes. Others hold none and delegate to something upstream. That decision drives your backup plan.
- MFA that you can actually enforce. TOTP is the floor. WebAuthn or passkeys are what you want for anything reachable from outside the house.
- Group-based access rules. “Everyone who can log in can reach everything” is not access control. You want per-application policy tied to group membership.
- What it costs you in RAM and moving parts. A Postgres plus Redis plus server plus worker stack is fine on a NAS with 16 GB. It is not fine on a Raspberry Pi already running twelve containers.
- A break-glass path. When the identity provider is down, you need a documented way back into your own infrastructure that does not depend on the identity provider.
Quick comparison
| App | Best for | Own user store | Protocols | Forward auth | License |
|---|---|---|---|---|---|
| Authentik | A full identity provider with a web UI | Yes | OIDC, SAML, LDAP, RADIUS | Yes, proxy outpost | MIT core, paid enterprise tier |
| Authelia | A light portal beside your reverse proxy | Yes, file or LDAP | OIDC provider, forward auth | Yes, native | Apache 2.0 |
| Tinyauth | Getting any login in front of a few apps fast | Yes, plus OAuth and LDAP | OIDC, forward auth | Yes, native | AGPL 3.0 |
| LLDAP | One shared directory the rest can read | Yes, LDAP only | LDAP | No | GPL 3.0 |
| oauth2-proxy | Bolting an existing IdP onto one app | No | OIDC and OAuth2 client | Yes, via nginx auth_request | MIT |
| Zitadel | Audit trails and multi-tenant setups | Yes | OIDC, SAML, SCIM, LDAP | Via OIDC | AGPL 3.0 |
| Keycloak | The widest protocol and federation coverage | Yes | OIDC, SAML | Via oauth2-proxy | Apache 2.0 |
| Pomerium | Per-request policy at the proxy itself | No | OIDC client | It is the proxy | Apache 2.0 |
Why the identity layer is the one people skip
Reverse proxy guides are everywhere, and they end at the point where traffic reaches the app. Firewall guides end at the port. Neither answers the question that matters once a hostname is public: who is allowed through, proven how, and revoked when.
The result is a home lab where the reverse proxy is well configured and the applications behind it are each protected by whatever their developer shipped. Some have TOTP. Some have a single shared admin password in an environment variable. Some have a setup wizard that stays open until somebody visits it. An identity provider in front of all of them turns that uneven surface into one door, and the door is the only thing you have to get right.
The apps
1. Authentik: best overall for self-hosted SSO
Authentik is the one most home labs end up on, and for a good reason: it covers both halves of the problem. Apps that speak OIDC or SAML get a proper identity provider with a discovery endpoint, group claims, and consent screens. Apps that speak nothing get a proxy outpost, which your reverse proxy calls as forward auth and which passes the authenticated username and email downstream as headers. Everything is configured through a web UI, including the flow builder, which lets you decide exactly when MFA is demanded and when a session can be reused. Enrollment, recovery, and password reset are self-service, which matters the moment somebody other than you needs an account.
Where it falls short: it is the heaviest of the lightweight options. The default deployment is a server container, a worker container, Postgres, and Redis, and the project asks for roughly 2 CPU cores and 2 GB of RAM before you add anything. The flow system is powerful and correspondingly easy to misconfigure, and a broken authentication flow locks you out of the admin interface as effectively as it locks out everyone else.
Cost: the core is MIT-licensed and free with no user limits. A paid enterprise tier adds support and features aimed at companies rather than households.
Platforms: Docker or Kubernetes on Linux, and Docker Desktop on Windows and macOS.
Download: goauthentik.io · GitHub
Bottom line: run Authentik for self-hosted SSO if you want one system that handles both the modern apps and the ones that will never implement OIDC, and you have the RAM to spare.
2. Authelia: best lightweight option with config you can version control
Authelia is a single Go binary that sits next to your reverse proxy and answers one question per request. Users live in a YAML file or an LDAP directory that Authelia does not own, access rules live in the same YAML, and the whole configuration is one artifact you can commit to a private repository and restore in a minute. It supports TOTP, WebAuthn security keys, Duo push, and passkeys, and it is OpenID Certified as an OIDC provider, so apps that speak OIDC can talk to it directly rather than going through headers. Forward auth integrations are documented for nginx, Traefik, Caddy, HAProxy, and Envoy.
Where it falls short: there is no admin UI. Adding a user means editing a file and reloading, which is fine for a household and painful for anything larger. Password reset needs a working mail configuration. The OIDC client registration syntax is unforgiving, and a typo in a redirect URI produces an error message that does not tell you which of the two ends is wrong.
Cost: free and Apache 2.0 licensed.
Platforms: Docker or a static binary on Linux, plus Docker on Windows and macOS.
Download: authelia.com · GitHub
Bottom line: the right pick if your access rules are stable, you are comfortable in YAML, and you would rather back up one file than one database.
3. Tinyauth: best for getting a login in front of things this evening
Tinyauth is what you reach for when Authelia feels like too much ceremony. One container, one config, and a login page in front of whatever your reverse proxy routes to it. It handles local users, LDAP, and OAuth logins from providers like GitHub and Google, supports TOTP, and applies per-application access rules. Version 5.1.0 picked up OpenID Certification for the Basic OP profile in mid-2026, so it is no longer only a forward-auth shim: apps that speak OIDC can use it as their provider. Documented integrations cover Traefik, nginx, and Caddy.
Where it falls short: it is young, and the project itself warns that configuration changes often between releases, so upgrades need reading release notes rather than pulling a new tag blindly. There is no SAML, no RADIUS, and no self-service enrollment for people who are not already in the directory. If your home lab grows past a handful of services with distinct groups, you will outgrow it.
Cost: free and AGPL 3.0 licensed.
Platforms: Docker on Linux, Windows, and macOS.
Download: tinyauth.app · GitHub
Bottom line: the fastest honest answer to “there is no login in front of this at all,” and small enough that it costs almost nothing to run alongside something bigger later.
4. LLDAP: best for one user directory everything else can read
LLDAP is not an SSO portal. It is a small Rust server that speaks enough LDAP for other software to authenticate against, with a web UI for managing users and groups and an option for users to reset their own password by email. That narrow scope is the point: Authelia, Authentik, Keycloak, Nextcloud, Jellyfin, and a long list of self-hosted apps can all read from it, so you get one place where accounts are created and one place where they are disabled. It stores data in SQLite by default, with MySQL, MariaDB, and PostgreSQL as alternatives, and exposes a GraphQL API if you manage users from code.
Where it falls short: it deliberately is not a full LDAP server. Generic LDAP browsers often fail against it, its password hashing scheme means it cannot hand out hashes for another service to validate, and the project names Synology as incompatible. It does no authorization of its own, so something else still has to enforce access rules.
Cost: free and GPL 3.0 licensed.
Platforms: Docker or a binary on Linux, and Docker on Windows and macOS.
Download: GitHub
Bottom line: pair it with Authelia or Tinyauth when you want a shared directory without standing up a real LDAP deployment, and skip it entirely if your identity provider already owns your users.
5. oauth2-proxy: best for putting an IdP you already run in front of one app
oauth2-proxy holds no accounts of its own. It is a client that sends visitors to an OIDC or OAuth2 provider you already have, checks the result, and then either proxies the request through to your application or answers nginx’s auth_request with a yes or no. It supports generic OIDC alongside dedicated integrations for Google, Microsoft Entra ID, GitHub, and others, and provider-specific implementations can pull group membership and forward it downstream as headers. It is a CNCF Sandbox project and it has been quietly doing this job for years.
Where it falls short: it solves exactly one problem and expects you to have solved the others. There is no user management, no MFA of its own, and no policy engine beyond allow-lists of emails, domains, and groups. Getting group claims through to an application means matching your provider’s claim names by hand, and the failure mode is a successful login with no permissions.
Cost: free and MIT licensed.
Platforms: Docker or a binary on Linux, macOS, and Windows.
Download: oauth2-proxy docs · GitHub
Bottom line: the correct choice when you already run Authentik, Keycloak, or Zitadel and need one stubborn app to respect it.
6. Zitadel: best when you want an audit trail of every identity event
Zitadel is a Go identity platform built on event sourcing, which means every change to a user, a role, or a session is stored as an immutable event rather than an updated row. For a home lab that sounds like overkill until the first time you need to answer when an account was created and by whom. It covers OIDC, SAML 2.0, OAuth 2.0, SCIM 2.0, and LDAP, supports OTP over app, email, and SMS, plus U2F and FIDO2 passkeys, and is multi-tenant from the ground up if you host services for more than one household or a side business.
Where it falls short: it requires PostgreSQL 14 or later, and the setup assumes you understand the organization and project model before you create your first application. The API-first design is excellent if you script your infrastructure and heavier than necessary if you just want a login page. Self-hosting is AGPL 3.0, which is worth reading if you plan to build anything commercial on top.
Cost: free to self-host. The hosted service is billed separately.
Platforms: Docker or Kubernetes on Linux, plus binaries for Linux and macOS.
Download: zitadel.com · GitHub
Bottom line: pick Zitadel over Authentik when compliance-style logging or multi-tenancy is a real requirement rather than a nice idea.
7. Keycloak: best for the widest protocol and federation coverage
Keycloak is the enterprise option, now a CNCF project with more than a decade of production use behind it. If a piece of software supports SSO at all, it almost certainly documents a Keycloak integration. It federates against existing LDAP and Active Directory, brokers to external providers, does fine-grained authorization with its own policy engine, and handles the awkward SAML corners that lighter tools skip. Getting started is genuinely quick with start-dev in Docker, which runs against an embedded database for evaluation.
Where it falls short: start-dev is not a production configuration, and moving to one means an external database, a hostname configuration that trips up almost everyone the first time, and a Java runtime whose memory use starts where Authelia’s finishes. It has no forward-auth mode of its own, so apps that do not speak OIDC or SAML need oauth2-proxy in front of them. The admin console assumes vocabulary (realms, clients, mappers) that no home lab guide will have taught you.
Cost: free and Apache 2.0 licensed.
Platforms: Docker or a Java distribution on Linux, Windows, and macOS.
Download: keycloak.org · GitHub
Bottom line: worth the setup cost if you need SAML federation or you are practising for the same stack at work, and hard to justify for six containers behind Traefik.
8. Pomerium: best for policy decided per request, not per login
Pomerium inverts the usual arrangement. Instead of an identity provider that grants a session and a proxy that trusts it, Pomerium is the proxy, and it evaluates a policy on every single request using identity from an upstream OIDC provider plus context about the request itself. Policies are written as configuration rather than clicked together, so access rules live in the same repository as the rest of your infrastructure. It is clientless, meaning nobody has to install a VPN app to reach an internal service, and it is Apache 2.0 licensed with a separately sold managed control plane for organizations that want a GUI.
Where it falls short: it holds no users, so you still need Authentik, Keycloak, Zitadel, or a hosted provider behind it. The typical deployment is more than one container with persistent storage. And because it replaces your reverse proxy rather than sitting beside it, adopting Pomerium means redoing routing and certificates that already work, which is a lot of churn for a home lab that just wants a login page.
Cost: free and open source to self-host. The hosted control plane is a paid product.
Platforms: Docker or Kubernetes on Linux, plus binaries for Linux and macOS.
Download: pomerium.com · GitHub
Bottom line: the pick when access decisions need to account for more than “this person logged in an hour ago,” and overkill for anything smaller.
The friction nobody mentions in the setup guides
Half your apps do not speak OIDC. Forward auth is the fallback: the reverse proxy asks the identity provider, and on success passes headers like Remote-User and Remote-Email to the app. That only works if the app can be configured to trust those headers, and it is only safe if the app is unreachable except through the proxy. Bind the container to an internal Docker network rather than a host port, because an app that trusts identity headers will trust them from anyone who can reach it directly.
When the identity provider is down, everything is down. Postgres fills a disk, a container update fails, a certificate expires, and suddenly nothing in the house logs in. Decide the break-glass path before you need it: keep at least one route to your infrastructure that does not traverse the identity provider, such as SSH over a mesh VPN or console access on the local network, and know which service you would temporarily exclude from forward auth to restore the rest. Write it down somewhere that is not behind the login you just lost.
Backups have to cover the identity store, not just the config. For Authelia the state is a YAML file plus a small database of TOTP and WebAuthn registrations. For Authentik, Zitadel, or Keycloak it is a Postgres database plus a secret key, and restoring the database without the matching secret gives you a service that starts and then refuses every session. Dump the database on a schedule, store the secret separately, and test a restore once rather than discovering the gap during an outage.
SSO in front of a media server breaks the native apps. This is the specific trap in the Plex scenario. A television app or a mobile client cannot complete a browser-based login flow, so putting forward auth across the whole hostname stops those clients from connecting at all. The usual workaround is excluding the API paths from SSO, which quietly returns you to the media server’s own authentication for exactly the traffic that carries your library. The cleaner answer is to keep native-client traffic on a mesh VPN and apply SSO to the web interface only, or to use an identity provider that the media server supports directly rather than wrapping it from outside.
Never make the identity provider the weakest link. Its admin interface should be reachable only from your internal network or over the VPN, MFA should be mandatory for every account that can change policy, and certificate verification stays on everywhere. A misconfigured identity provider is worse than none, because it concentrates access instead of distributing it.
How to pick the right one
- If you want one system that covers both OIDC apps and header-only apps: Authentik.
- If you want your entire access policy in a file you can back up and diff: Authelia.
- If nothing has a login yet and you want that fixed tonight: Tinyauth.
- If you already have several apps that read LDAP and no central directory: LLDAP.
- If you already run an identity provider and one app refuses to use it: oauth2-proxy.
- If you need an audit trail or you host services for more than one group of people: Zitadel.
- If you need SAML federation or you want to learn the stack your workplace runs: Keycloak.
- If access should be re-evaluated per request rather than per session: Pomerium.
For most people opening a home server to the internet for the first time, the honest answer is Authentik if the hardware can carry it, and Authelia if it cannot. Both give you one login, enforced MFA, and one place to revoke access, which is the whole point.
FAQ
What is the best self-hosted SSO solution for a home lab?
Authentik covers the widest range of situations, because it works as a full identity provider for apps that speak OIDC or SAML and as a forward-auth gateway for apps that speak neither. Authelia is the better fit on constrained hardware or when you want the entire configuration in a version-controlled file. Both are free and both enforce MFA across every service behind them.
Do I need SSO if my reverse proxy already has TLS and a password?
They solve different problems. TLS protects traffic in transit and basic auth protects a single hostname with a shared secret that cannot be revoked per person or backed by MFA. SSO gives each person their own identity, enforces a second factor once for everything, and lets you remove access in one place. A reverse proxy is where SSO is enforced, not a substitute for it.
Can I put SSO in front of Plex or Jellyfin?
Partly. The web interface works fine behind forward auth. Native apps on phones, televisions, and streaming boxes cannot complete a browser login, so they break unless you exclude the API paths, which weakens the protection for the traffic that matters most. Keep native clients on a mesh VPN and protect the web interface with SSO, or use an identity provider your media server integrates with directly.
What happens if my identity provider goes offline?
Every service behind it stops accepting logins, and existing sessions expire on their normal schedule. Plan for it: keep local network or VPN access to your host that does not depend on the identity provider, keep a documented way to disable forward auth on one service, and store recovery codes and database backups somewhere reachable without logging in.
Is Keycloak overkill for a home server?
Usually, yes. Keycloak’s strengths are SAML federation, brokering to external providers, and fine-grained authorization at organizational scale, and its cost is a Java runtime, an external database, and a vocabulary you have to learn first. For a dozen containers behind a reverse proxy, Authentik or Authelia deliver the same practical outcome with far less setup.
Do these tools store my passwords, and how do I back them up?
Authentik, Authelia, Zitadel, Keycloak, LLDAP, and Tinyauth all hold credentials in some form. oauth2-proxy and Pomerium hold none and delegate upstream. For the ones that do, back up the database or configuration file together with the instance secret key, because a restore without the matching secret invalidates every session and enrolled second factor.
