Authentik: Single Sign-On for Self-Hosted Services

Anyone running multiple self-hosted services in an SMB or homelab knows the problem: every service has its own login. Nextcloud, GitLab, Vaultwarden, Portainer, Grafana — each with its own user management, its own passwords, its own MFA setup or none at all. When an employee changes roles, the admin clicks through five to ten user profiles, disables each one individually and hopes nothing gets missed.

Authentik (spelled with a “k”, formerly known as passbook) solves exactly this: a central identity provider that all services hang off — with single sign-on, MFA and lifecycle management from one place.

What Is Authentik?

Authentik is an open-source IdP (identity provider), developed by BeryJu under the MIT license, written in Python/Go with a React frontend. It positions itself between lightweight auth proxies like Authelia and heavyweight enterprise suites like Keycloak.

What Authentik delivers:

• OIDC provider for modern web apps (Nextcloud, GitLab, Grafana, Vaultwarden)
• SAML2 provider for legacy apps that do not speak OIDC
• LDAP frontend — Authentik can act as an LDAP server that old applications authenticate against
• Proxy provider as a forward auth proxy (similar to Authelia/oauth2-proxy) for services without their own SSO
• MFA: TOTP (authenticator apps), WebAuthn (FIDO2/Passkey), Duo Push, SMS (not recommended), static codes
• Flows: a visual editor for login, registration and recovery processes — from “classic password” to “passwordless with magic link”
• Outposts: helper containers that project Authentik into other networks (e.g. a proxy outpost in the DMZ)
• Audit log and event system with configurable webhooks for SIEM integration

Authentik typically runs as a Docker Compose stack or in a Kubernetes cluster — the Helm chart is officially maintained.

Authentik vs. Authelia — Which Tool When?

Both tools come up in discussions, but they solve slightly different problems:

Criterion	Authelia	Authentik
Goal	lightweight auth proxy with MFA	full IdP with flows and lifecycle
Main mode	forward auth in front of reverse proxy	OIDC/SAML/LDAP/Proxy, freely chosen
Configuration	YAML files	WebUI with flow editor
Resource footprint	minimal (Go binary)	medium (Python/Django + PostgreSQL + Redis)
User management	YAML or LDAP backend	own DB with WebUI, LDAP sync possible
Complexity feel	auth proxy with extras	IdP suite
Learning curve	flat for forward auth	steeper, but more options
Typical audience	homelab, small setups	SMB, larger homelabs, IdP requirement

Rule of thumb: If you need an auth proxy in front of a few web services and are happy with YAML config, Authelia is easier. If you need a real identity provider — e.g. because OIDC federation with third parties is coming or because the SMB is going long-term on SSO — Authentik gives you more options without falling into Keycloak complexity.

Architecture Overview

   User  ─────►  Reverse proxy (nginx/traefik)
                          │
              ┌───────────┴────────────┐
              ▼                        ▼
   Authentik server           Service (Nextcloud)
   (OIDC/SAML/Proxy)            │
              │                 │
              ▼                 ▼
        PostgreSQL  ◄───── OIDC flow ──────►
        Redis

• User reaches the service via the reverse proxy
• The service redirects to the Authentik server for login
• Authentik checks credentials plus MFA and returns a token/assertion
• The service accepts the token and grants access

Setup: Authentik via Docker Compose

The official docker-compose.yml pulls the Authentik server and worker plus PostgreSQL and Redis. The key variables:

# .env (excerpt)
PG_PASS=<strong-password>
AUTHENTIK_SECRET_KEY=<openssl rand -base64 32>
AUTHENTIK_ERROR_REPORTING__ENABLED=false
AUTHENTIK_BOOTSTRAP_PASSWORD=<initial-akadmin-password>
AUTHENTIK_BOOTSTRAP_TOKEN=<initial-api-token>

# Behind your own reverse proxy
AUTHENTIK_LISTEN__HTTP=0.0.0.0:9000
AUTHENTIK_LISTEN__HTTPS=0.0.0.0:9443

After startup, the akadmin account is configured at /if/flow/initial-setup/. Then the real work begins: create a provider and an application for each service.

Example 1: Nextcloud via OIDC

Nextcloud supports OIDC via the “OpenID Connect Login” app or the “OpenID Connect User Backend”. In Authentik:

1. Create a provider: type “OAuth2/OpenID Provider”, redirect URI to https://cloud.example.com/apps/user_oidc/code
2. Create an application: slug “nextcloud”, link the provider
3. Note public key / client ID / secret

In Nextcloud under Administration -> OpenID Connect Login:

• Identifier: authentik
• Authorize URL: https://auth.example.com/application/o/authorize/
• Token URL: https://auth.example.com/application/o/token/
• Userinfo URL: https://auth.example.com/application/o/userinfo/
• Logout URL: https://auth.example.com/application/o/nextcloud/end-session/

On the first login a Nextcloud user is created automatically — from that point on, Authentik is the source of truth for existence and permissions.

Example 2: GitLab via OIDC

GitLab configures OIDC via gitlab.rb:

gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_providers'] = [
  {
    name: "openid_connect",
    label: "Authentik",
    args: {
      name: "openid_connect",
      scope: ["openid","profile","email"],
      response_type: "code",
      issuer: "https://auth.example.com/application/o/gitlab/",
      discovery: true,
      client_auth_method: "query",
      client_options: {
        identifier: "<client-id>",
        secret: "<client-secret>",
        redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback"
      }
    }
  }
]

On the Authentik side, create an OAuth2 provider plus application just like for Nextcloud. After gitlab-ctl reconfigure, the GitLab login page shows a “Sign in with Authentik” button.

Example 3: Vaultwarden via Proxy Provider

Vaultwarden has no built-in SSO support — the default architecture assumes users are created directly. To bundle this behind Authentik, use the proxy provider: Authentik acts as forward auth in front of the Vaultwarden reverse proxy. Only authenticated users even reach the Vaultwarden login page.

Upside: the Vaultwarden login page is not publicly reachable and brute force attacks already stop at Authentik. Downside: two logins (first Authentik, then Vaultwarden) — until Bitwarden/Vaultwarden ships native SSO, this is the clean transitional solution.

MFA: What Actually Makes Sense

Authentik supports multiple MFA types. In practice:

MFA type	Recommendation
WebAuthn / FIDO2 / Passkey	first choice — hardware token (Yubikey) or platform passkey
TOTP (authenticator app)	good backup, widely deployed
Duo Push	if Duo is already in place
Static codes	only as emergency backup, store in vault
SMS	not recommended — SIM-swapping risk

Via a flow you can enforce that MFA is set up at most on first login — or that MFA is mandatory for certain applications (e.g. Vaultwarden, GitLab) and optional for others.

Security Notes

A central IdP becomes a single point of failure and a single point of compromise. If you run Authentik in production, you should:

• Put Authentik itself behind MFA — admin login without MFA is off-limits
• TLS everywhere — never plain HTTP for Authentik
• Back up user database and settings: regular PostgreSQL dump, store the encryption key separately
• Watch the audit log — failed admin logins, token creation, new applications
• Patch discipline: Authentik publishes releases regularly, security issues are communicated via the repo
• Reverse proxy with fail2ban / rate limiting in front of Authentik
• Recovery plan: what happens if Authentik itself is down? Keep at least one local admin account per core system for emergency access

If you lose the IdP, you lose access to everything. That is both the argument for SSO (lifecycle management) and against careless SSO (bus factor).

When Is Authentik Worth It?

Sensible:

• More than 3-5 self-hosted services with user logins
• Multiple staff with different permission scopes
• Frequent staff turnover (lifecycle is otherwise a nightmare)
• Mandatory MFA across the service fleet
• Preparation for future B2B federation (customer login via OIDC)

Likely overkill:

• One or two services, one or two users
• Pure homelab that runs cleanly without SSO
• When central maintenance overhead exceeds decentral user management cost

Conclusion

Authentik fills the gap between “lightweight auth proxy” (Authelia) and “enterprise IdP suite” (Keycloak, Okta). For SMBs with a growing self-hosted fleet or homelabs with serious security requirements, Authentik is the sweet spot — provided that the central management overhead is justified by the number of attached services.

If you introduce Authentik, start with two or three services as a pilot — e.g. Nextcloud and GitLab — and add more services step by step. The learning curve is real but manageable. And the day an employee leaves and the admin disables the user in a single UI instead of clicking through seven profiles justifies the effort on its own.

Related Articles

• Vaultwarden: Self-Hosted Password Manager
• SSH Hardening: Secure Remote Access
• Linux Server Hardening Measures
• Fail2ban: Brute Force Protection