On this page
Picture the logins piling up. Immich for your photos, Grafana for your dashboards, a router admin page, a NAS, a Vaultwarden vault, three more things you stood up on a Sunday and half-forgot. Each one has its own account, its own password, and — if you were disciplined — its own second factor. I got tired of it. I wanted one front door.
That front door is what Authentik gives you. This post is the what and the why; the hands-on install lives in its own guide so this one can stay a clear-eyed overview you can read before you commit to running anything.
What Authentik actually is
Authentik is an open-source identity provider — an IdP, in the jargon. An identity provider is the one service that knows who your users are, and that every other app agrees to trust. Instead of each app checking a password itself, it hands that job off: “go ask Authentik whether this person is really who they claim to be, and come back and tell me.”
The official one-liner is that it’s “an open-source Identity Provider for modern SSO.” SSO — single sign-on — is the payoff: you log in once, and every connected app treats you as logged in. No more re-typing the same password into a dozen dashboards. Authentik is a real, actively developed project from Authentik Security, Inc., with the core released under the permissive MIT license and a separate paid Enterprise edition layered on top.
Here is the shift in shape, before and after:
The apps no longer store your password. They store trust: a standing agreement that a token signed by Authentik means “this person is authenticated, let them in.” That single change is the whole idea.
The protocols it speaks
The reason one IdP can sit in front of such different apps is that Authentik speaks the standard languages apps already use to delegate login. You don’t have to memorize these, but it helps to recognize them when an app’s settings page asks:
- OAuth2 and OpenID Connect (OIDC) — the modern default. OAuth2 is the framework most “Log in with…” buttons are built on, and OpenID Connect is the identity layer on top of it. Most well-behaved self-hosted apps support it.
- SAML — the older enterprise standard, still everywhere. If an app mentions SAML, Authentik can be its identity provider too.
- LDAP — for older software that only knows how to check a username and password against a directory. Authentik can be that directory, so legacy apps authenticate against your accounts without special support.
- RADIUS — for things like VPNs and network gear that speak this decades-old protocol rather than anything web-shaped.
- Proxy (forward authentication) — the clever one. For an app with no login support at all — a bare dashboard, an admin panel someone never secured — Authentik can put its own login screen in front of it, and only pass traffic through once you’ve signed in.
That last mode is where an IdP and a reverse proxy start to overlap. Your proxy already decides which app a request reaches; forward auth lets Authentik veto the request unless you’re logged in. It’s how you retrofit a login onto something that shipped without one.
Flows and stages: the part that makes Authentik Authentik
Plenty of tools can check a password. What sets Authentik apart is that the login process itself is something you assemble, not a fixed screen. Authentik calls a login sequence a flow, and each step in it a stage — identify the user, check the password, demand a second factor, show a consent screen, and so on. You arrange those stages like beads on a string.
That flexibility sounds like over-engineering until you want something specific: require a second factor only for admins, let a guest self-enroll with just an email, or drop straight to a passkey and skip the password entirely. You’re not waiting for a feature flag — you’re rearranging stages you already have.
Multi-factor, the way you’d hope
Because that second-factor step is just another stage, Authentik supports a broad set of factors and lets you decide where each one applies. The official documentation covers all of them; the ones a homelabber reaches for:
- TOTP — the six-digit codes from an app like Google Authenticator, Authy, or 1Password.
- WebAuthn / passkeys — a YubiKey, your laptop’s fingerprint reader, or a phone passkey. Phishing-resistant and, honestly, nicer to use than typing codes.
- Static recovery codes — the one-time backup codes you print and hide for the day you lose your phone.
- SMS, Duo, and email — available too, though SMS is the weakest of the set and worth avoiding where a passkey will do.
Setting MFA once, centrally, and having it apply to every connected app is one of the strongest reasons to run an IdP at all. It’s the same instinct behind hardening the hypervisor underneath everything: fix the security in one place that everything else depends on.
So — do you actually want this at home?
I’ll be honest, because the runbook I write to demands it: single sign-on is not free, and it is not for everyone.
Skip it if you run a handful of services. Two or three apps, each with a strong unique password in Vaultwarden, is simpler, has fewer moving parts, and won’t lock you out of everything at once when the identity service hiccups. Adding an IdP there is solving a problem you don’t have yet.
Reach for it when the list has grown past what you enjoy managing by hand — when you’re re-entering the same credentials all day, when you want one enforced MFA policy across everything, or when “who has access to what” has become a question you can’t answer quickly. An IdP turns access into one dial you control, instead of a dozen scattered checkboxes.
There’s also a real risk to name: Authentik becomes a single point of failure. If it’s down, every app that trusts it can lock you out. That’s a manageable trade — keep a break-glass local admin on critical apps, back the database up, and don’t route your emergency access through the thing you might need to fix. But it’s a trade you should make on purpose.
What it costs to run
Authentik is heavier than a single small container, and it’s fair to know that up front. A standard deployment is three pieces working together:
- the server, which handles logins, the API, and the admin interface (and carries a built-in “embedded outpost” so basic proxy auth works with nothing extra to deploy);
- a worker, which runs background jobs like sending email and scheduled tasks;
- a PostgreSQL database, which stores all of its configuration and data.
(Older releases also ran a separate Redis container for caching and the task queue; recent versions no longer ship one in the official Compose file.)
For the LDAP, RADIUS, or heavier proxy roles, you add small helper services called outposts — lightweight processes that sit next to those apps and talk back to the server. Under the hood the server is written in Python and the outposts in Go, but you don’t touch either; you run containers.
None of it is exotic. It sits comfortably in a small VM or LXC container with a couple of gigabytes of RAM, and Docker Compose is the usual way to stand it up. If you already run a Docker host for your other stacks, Authentik is one more compose file — a meaningful one, but not a special snowflake.
Where to go next
If this sounds like the front door you’ve been missing, the companion how-to guide walks through actually deploying it — the compose file, the first flow, and wiring your first app to it. And if you haven’t yet put your services behind clean HTTPS URLs, do that first: a reverse proxy is the natural place Authentik plugs in, and the two are much easier to reason about together than apart.
Related posts:
- How to Set Up Authentik with Docker Compose — the hands-on companion: install it, set your first admin, and protect a test app.
- What Is Traefik? The Reverse Proxy, Explained — the layer Authentik’s forward-auth plugs into; read this first if reverse proxies are new to you.
- Traefik + Let’s Encrypt: Automatic HTTPS — get clean HTTPS URLs in place before you add single sign-on in front of them.
- Run Vaultwarden in a Proxmox LXC — the password manager that complements an IdP rather than competing with it.
- Harden Proxmox Before You Expose Anything — the same “secure the shared foundation once” instinct, one layer down.
- Tailscale Subnet Router for Your Homelab — the other half of secure access: a private network to reach the apps Authentik protects.
- Reach Plex From Anywhere Over Tailscale — a concrete example of exposing a service safely without opening it to the world.
Comments
Comments are powered by GitHub Discussions — sign in with a GitHub account to join the conversation.