Authentik: one login for the entire homelab

May 8, 2026

Picture this: you’ve got eight services running in your homelab. Proxmox for the hypervisor, Gitea for code, Grafana for metrics, a password manager, a container registry, maybe a remote desktop gateway. Each one has its own login page. Each one has its own username and password — unless you did the lazy thing and made them all the same password, which is worse.

This is the password sprawl problem, and it scales badly. Add a service, add a credential. Rotate a password, do it eight times. Let a family member in, create eight separate accounts. Revoke access, do it eight times — and hope you got them all.

In an enterprise, you solve this with an Identity Provider: one authoritative system that knows who you are, and every other service defers to it. When you log into Okta or Microsoft Entra ID at work, you’re using this model. The service you want doesn’t hold your credentials at all. It asks the identity provider, “is this person who they say they are?” and the IdP says yes or no.

You can run the same thing at home, and you probably should.

What is an Identity Provider?

An Identity Provider (IdP) is a service that stores user accounts, handles authentication, and issues cryptographic proof that a user logged in successfully. It speaks standard protocols: OIDC (OpenID Connect) and OAuth 2.0 for modern web apps, SAML for older enterprise apps, and LDAP for network gear and software that predates the web-based standards.

The pattern looks like this:

1. You try to open a service — say, your Grafana dashboard.
2. Instead of showing you a login form, Grafana redirects you to your identity provider.
3. You log in once at the IdP.
4. The IdP issues a signed token and sends you back to Grafana.
5. Grafana trusts the token. You’re in.

From that point forward, opening any other SSO-integrated service just works — you’re already authenticated. This is the “single sign-on” in SSO. One session, everywhere.

Why not just use Okta or Microsoft Entra?

Okta and Microsoft Entra ID (formerly Azure Active Directory) are the dominant enterprise identity platforms. They’re excellent, well-supported, and deeply integrated into the corporate ecosystem. They’re also priced for organizations, not homelabs.

⚠️ Unverified: Okta pricing starts at a per-user monthly fee and is generally aimed at business deployments; free tiers are limited.

⚠️ Unverified: Microsoft Entra ID is included with Microsoft 365 Business plans; standalone licensing exists but is similarly enterprise-oriented in cost structure.

More importantly, even if the cost were zero, these are cloud-hosted services. Your authentication traffic goes through someone else’s infrastructure. If their service is down — or if you’re testing something on an air-gapped lab — your login flow breaks. A self-hosted IdP lives on your hardware, works whether your internet connection is up or not, and doesn’t report home to anyone.

The self-hosted options

If you decide to run your own identity provider, there are three names you’ll encounter most often:

Keycloak is the oldest and most feature-complete open-source IdP. It handles virtually every enterprise identity scenario imaginable. The trade-off is complexity: Keycloak’s configuration surface is enormous, the UI has historically been dense, and it’s a heavy Java application with meaningful resource requirements. It’s the right answer for organizations that need every edge-case feature. For a homelab, it can feel like overkill.

Authelia is a lightweight access-control layer that sits in front of your reverse proxy. It does authentication and authorization well and is genuinely simple to configure. The catch is scope: Authelia is primarily a forward-auth guard for reverse-proxy setups. It doesn’t speak OIDC as a full provider the same way a dedicated IdP does, and it has less native support for LDAP serving, application-level SSO flows, and user self-service. Great for protecting services behind a proxy; not quite a full identity platform.

Authentik sits between the two in complexity, and in practice hits the homelab sweet spot. It’s a full OIDC/SAML/LDAP identity provider with an approachable web UI, active development, and good documentation. It can serve as a reverse-proxy guard like Authelia and as a proper OIDC IdP like a lighter Keycloak. It handles user enrollment flows, MFA, groups, policy enforcement, and even a built-in application launcher (a portal your users land on after login). For a homelab running a dozen self-hosted services, it’s enough without being overwhelming.

How Authentik fits into a real homelab

This lab runs Authentik as a dedicated VM — a single instance that handles authentication for every service that supports it. Here’s what that looks like in practice.

OIDC for web services. Every modern self-hosted application with SSO support can talk OIDC. In this lab, that list includes the hypervisor management interface, the Git hosting service, the secrets manager, the monitoring dashboards, the password manager, the remote desktop gateway, the container registry, and the container management UI. Each service gets its own OIDC “provider” configured in Authentik — essentially a client registration that tells Authentik where to redirect after login and what user attributes to share.

The result: log in once, and all of those services recognize you for the rest of your browser session.

LDAP for legacy things. Some services don’t understand modern protocols at all. Out-of-band management hardware — the kind you use to remotely power cycle servers — often only speaks LDAP. Authentik includes a built-in LDAP outpost: a component that presents your Authentik user directory as a standard LDAP directory. Hardware that would never support OIDC can still authenticate against your central identity store.

Not everything integrates. This is worth being honest about: not every self-hosted service supports SSO. Some have no external authentication at all. Others support only a single local admin account. In this lab, the monitoring alert system and the DNS management UI fall into this category — they use separate local credentials and will probably always need to. You accept that tradeoff and focus SSO effort on the services where it pays off most.

Groups and policies. Authentik lets you assign users to groups and attach policies to those groups. An “admins” group can access the hypervisor web UI; a “users” group might only reach the media server. You manage access centrally, and services consume the group membership from the OIDC token. Add someone to a group, and all their service permissions update immediately. Remove them from the group, and all their service permissions are revoked in the same step.

Backup. The Authentik configuration — providers, applications, policies, user accounts — lives in a database. It goes into the daily backup rotation alongside every other service. If the Authentik VM has to be rebuilt from scratch, the configuration is restorable.

The setup experience

Deploying Authentik isn’t a one-click install, but it’s not particularly difficult either. The standard path is a Docker Compose stack: a server container, a worker container, a PostgreSQL database, and a Redis cache. The official documentation covers this well.

Initial configuration is done through a web-based wizard that runs on first boot. You create your admin account, and then the real work begins: registering each service as an “application” with a corresponding “provider” in Authentik’s admin interface.

Each integration is a small project. OIDC integrations follow a consistent pattern:

1. Create a provider in Authentik, set the redirect URI to the service’s callback endpoint, note the client ID and secret.
2. In the service, enable OIDC authentication, paste in the discovery URL and the credentials from step one.
3. Test by logging out and logging back in via SSO.

The first two or three integrations take some reading. After that, the pattern is mechanical.

LDAP is a bit different — you’re deploying an outpost, configuring bind credentials, and then pointing the LDAP-speaking service at Authentik’s LDAP listener. This is more finicky but well-documented.

The integration that tends to take the most thought is the first one, because you’re also establishing the patterns: how you name providers, what groups you create, what attribute mappings you use. Getting those consistent early saves a lot of cleanup later.

One thing worth planning before you start: decide on your group structure. A two-tier model — an admins group with full access and a users group with access to non-infrastructure services — covers most homelab scenarios. You can always refine it later, but having groups defined before you wire up your first application means the permissions model is in place from day one rather than bolted on afterward.

Authentik also supports multi-factor authentication. You can enforce TOTP (authenticator app codes) or passkeys for specific applications or for all logins. For anything exposed to the internet, enabling MFA at the IdP layer is a meaningful security improvement — instead of wiring up MFA separately in each service (if it supports it at all), you handle it once, in one place, and every SSO-integrated service inherits it.

Who should bother

You should seriously consider an IdP if:

• You’re running five or more self-hosted services.
• Other people (family, trusted friends) need access to some but not all of those services.
• You’ve found yourself copying and pasting credentials, reusing passwords across services, or maintaining a spreadsheet of per-service logins.
• You want a proper audit trail — who logged into what, and when.

You can probably skip it if:

• You’re running one or two services, access them only yourself, and the overhead isn’t worth it to you.
• Your homelab is purely for learning Docker and you’re not exposing anything to the network long-term.
• You’re just starting out and haven’t hit credential sprawl yet. (You will. Come back when you do.)

The investment — maybe half a day to deploy and wire up a handful of services — pays dividends every time you add something new to the lab. With SSO in place, adding a new service that supports OIDC goes from “create an account and store a new password” to “register a provider and test the redirect.” It’s a different relationship with the services you run.

The larger point

Single sign-on isn’t glamorous. It doesn’t add features to any individual service. It doesn’t give you a cool dashboard to look at. What it does is turn a collection of independent applications into something that behaves like a coherent system — one where access is centrally managed, easily granted, easily revoked, and consistently audited.

That’s the enterprise pattern, and it belongs in the homelab too. The infrastructure pieces exist, they’re free, and they’re genuinely good. Running your own identity provider is one of those things that’s slightly annoying to set up and then immediately makes everything else better.

One login. Everywhere. Worth it.

← all posts