Security

authentik: The Open-Source SSO Platform That Speaks SAML, OIDC, LDAP, and RADIUS

If you run more than three self-hosted apps, you already know the feeling: every single one has its own account, its own password, its own MFA situation, when it bothers to have one at all. A Nextcloud here, a Grafana there, an internal dashboard next to a wiki and a VPN. Eventually you either start reusing the same password everywhere, which defeats the whole point, or you end up with a password manager holding fifteen entries just for your own tools. “One login for everything” is appealing precisely because it fixes the problem at the root: one place to manage users, one place to enforce MFA, one place to revoke access when someone leaves. The catch is that getting there means introducing a new, critical piece of infrastructure: a self-hosted identity provider (IdP) that everything else now depends on.

authentik (GitHub repo , official site at goauthentik.io ) is exactly that: a self-hosted, open-source identity provider and SSO platform built to cover a wide range of authentication protocols instead of just one. It isn’t a thin proxy that slaps a login page in front of an app; it’s a full identity system, with users, groups, policies, and configurable authentication flows.

What authentik actually is

authentik doesn’t try to be just one thing: it speaks SAML, OAuth2/OpenID Connect (OIDC), LDAP, SCIM for automated account provisioning, and RADIUS for network- and VPN-level authentication. That covers the four different ways modern (and not-so-modern) systems talk about “who are you”: web apps that understand OIDC or SAML, legacy services expecting a classic LDAP directory, provisioning systems that speak SCIM, and network gear expecting RADIUS. Instead of running three or four separate tools for each of these, you run one that speaks all of them.

What really sets it apart, though, isn’t the protocol list, it’s the “flows and stages” engine. Instead of a hardcoded login screen, a fixed registration page, and a rigid password-recovery process, authentik models each of these as a configurable “flow” built from reusable “stages”: an identification stage, a password-verification stage, an MFA stage, a consent stage, and so on. You can build a different login flow for one group of users than for another, insert an extra stage only for admins, or enable self-registration (enrollment) for only certain applications. It’s flexible in the good sense of the word: you’re not stuck with the default design if you need something else.

Why it matters

The reason a centralized IdP is worth the investment is simple: every app you add without SSO is a new attack surface with its own authentication mechanism, usually weaker than you’d like (no MFA, no password-complexity policy, no centralized logging). When you centralize identity, you enforce a single MFA policy everywhere, you get one place to see who logged in where and when, and one switch to flip when someone leaves the team, instead of walking through ten apps closing accounts one by one.

To be upfront about it: DreamServer’s own internal SSO runs on Authelia , not authentik, mostly because Authelia’s lightweight single-binary/config-file model fit our stack better. That doesn’t make authentik the wrong choice, it’s a genuinely strong, more full-featured identity provider, especially if you need SAML, SCIM, RADIUS, or self-service enrollment flows that Authelia doesn’t attempt to cover. These are two tools built with different philosophies, not a winner and a runner-up.

What you get out of the box

The feature set in authentik goes well beyond “log in once, access everything”:

Real multi-protocol support: SAML and OIDC for modern web apps, LDAP for services expecting a classic directory (plenty of legacy apps, some NAS boxes, some enterprise tools), SCIM for automated account provisioning and de-provisioning in third-party services, and RADIUS for network-level or VPN authentication. You can effectively replace four different auth systems with one.
The flows-and-stages engine: login, enrollment (self-registration), password recovery, and other identity workflows are configurable flows, not fixed screens. You can add, remove, or reorder stages without writing code.
A forward-auth (proxy) provider: for applications that have no native authentication of their own, authentik can sit in front of them as a forward-auth provider and gate access, conceptually similar to what Authelia or oauth2-proxy do. Useful for internal tools, dashboards, or utilities with no login system of their own.
Solid MFA: TOTP (Google Authenticator and equivalents) plus WebAuthn/passkeys, so you can enforce passwordless or hardware-key authentication wherever you need that level of security.
An admin UI: you manage applications, providers, users, groups, and flows from a web interface instead of hand-editing configuration files for every small change.

Under the hood, the backend is built on Python/Django plus a Go component, and it’s typically self-hosted via Docker/docker compose or Kubernetes.

Installing authentik on a VPS

A VPS is a reasonable place to run authentik: you get full control over the network and the firewall, which matters a lot when you’re putting into production an identity system that everything else now depends on. The official install path uses docker compose, with a server service, a worker service (for asynchronous tasks like sending emails or processing more complex flows), plus PostgreSQL and Redis as dependencies:

mkdir -p /opt/authentik && cd /opt/authentik

# fetch the official compose file and generate secrets into a .env file
curl -o docker-compose.yml https://goauthentik.io/docker-compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env

# bring the stack up (server + worker + postgres + redis)
docker compose pull
docker compose up -d

The basic shape is simple enough: the server container serves the UI and the API, the worker processes background tasks, and Postgres and Redis hold state and the job queue. This is not a single binary, it’s a small stack of services that need to run together, and that’s worth factoring into your resource sizing and your operational expectations.

# allow only the HTTPS/HTTP traffic needed to reach authentik
ufw allow 80/tcp
ufw allow 443/tcp

# during initial setup, consider restricting access to the admin
# interface to your own IPs only (an extra rule on the admin path,
# or a reverse proxy allowlist), then relax it once MFA is enabled
# on the admin account

If you’d rather not deal with the OS, firewall, and server maintenance side of things yourself, server administration is exactly for this kind of work: you handle authentik’s configuration, we handle the rest.

Configuration patterns worth knowing

It’s tempting to leave the default login flow exactly as it ships, but it’s worth stopping to think about which stages you actually want: identification by email or username, password verification, then mandatory MFA for everyone or just for a specific group (admins, say). Because every stage is a separate object you can reorder or condition, you can build a different flow for internal users versus external or test accounts, without duplicating any logic.

Plenty of internal tools (dashboards, monitoring utilities, status pages) have no authentication mechanism at all, they simply assume that whoever reaches them is allowed to be there. authentik’s forward-auth provider solves exactly that: you point your reverse proxy to check the session against authentik before letting the request through, and the app behind it doesn’t even need to know an auth layer exists in front of it.

Choose OIDC, SAML, or LDAP based on what the app actually supports, not your preference

There is no universally “best” protocol, only what the target application supports. Modern, web-native apps almost always speak OIDC, less often SAML (common in enterprise or education environments). Older services or network gear often only speak LDAP. Check the target app’s documentation before you configure a new provider in authentik, not the other way around.

Enforce MFA policy from one place, not per application

One of the biggest wins of a centralized IdP is that you can enforce MFA (TOTP or WebAuthn/passkeys) at the login flow level, once, and that policy automatically applies to every application using authentik as its provider. No more configuring MFA separately in each app, with the risk of missing one and leaving a door open.

Where authentik is not the right answer

Let’s be direct: authentik is a heavier stack than it might look at first glance. Django plus a worker plus PostgreSQL plus Redis means four pieces that need to run together, get monitored, and get updated, compared to a config-file-plus-single-binary tool. If all you need is a simple forward-auth gate in front of a handful of self-hosted apps, no SAML, no SCIM, no RADIUS, the extra complexity probably isn’t worth the operational cost.

The flexibility of the flows-and-stages engine comes with its own price: the learning curve is not trivial. This isn’t a “configure it in five minutes and forget about it” system; you need to understand how stages compose and how policies interact before you’ll feel comfortable changing anything in production.

And if you already have a small homelab with a handful of apps and no real multi-protocol requirements, a simpler tool can get you 90% of the value with far less operational overhead. Not everything worth doing is worth doing with the most feature-complete tool available.

Alternatives we considered

Authelia is the most direct alternative: lighter, a single binary, configuration driven by a YAML file, built mainly for forward-auth SSO in front of a set of self-hosted apps. As mentioned above, it’s exactly what DreamServer runs internally, precisely for the operational simplicity. It doesn’t have authentik’s protocol ambitions (no native SAML, no SCIM, no RADIUS), but for a lot of use cases it covers exactly what you need without the extra ballast.

Keycloak sits at the opposite end in terms of enterprise maturity: a Java-based identity provider with protocol coverage as broad as authentik’s, but its own heavier JVM footprint and a different, more classically enterprise administration model. If you’re already deep in a Java-heavy ecosystem, or you need specific enterprise integrations, it’s worth a look.

Ory is worth mentioning for a different angle entirely: a componentized identity stack built more for developers and APIs first, where you pick the pieces you need (Kratos for identity, Hydra for OAuth2/OIDC, and so on) instead of a single monolith with an admin UI. It makes sense if you’re building your own product and want fine-grained control from code, less so if you want something ready to administer through a UI from day one.

So, should you run it?

If you need broad protocol coverage (SAML for an enterprise partner, LDAP for an aging NAS, RADIUS for VPN, OIDC for everything else), or you want configurable self-registration and password-recovery flows, or you have a pile of heterogeneous apps you want to put behind a single forward-auth gate, authentik is a solid, mature choice. If instead you want something easier to operate, with fewer moving parts, and protocol breadth isn’t a real requirement for you, consider Authelia before jumping into Django plus worker plus Postgres plus Redis.

Whichever you pick, a VPS with dedicated resources and full network control is the right place to run it, and if you’d rather not handle the system side yourself, server administration is there for exactly that.