Authentik: Single Sign-On für Self-Hosted-Dienste

Wer im KMU oder Homelab mehrere Self-Hosted-Dienste betreibt, kennt das Problem: Jeder Dienst hat sein eigenes Login. Nextcloud, GitLab, Vaultwarden, Portainer, Grafana — jedes mit eigener Userverwaltung, eigenen Passwörtern, eigenem MFA-Setup oder eben gar keinem. Wechselt ein Mitarbeiter die Stelle, hangelt sich der Admin durch fünf bis zehn Userprofile, deaktiviert überall einzeln und hofft, nichts zu vergessen.

Authentik (geschrieben mit “k”, früher unter dem Namen passbook bekannt) löst genau dieses Problem: Ein zentraler Identity-Provider, an dem alle Dienste hängen — mit Single Sign-On, MFA und Lifecycle-Management aus einer Hand.

Was ist Authentik?

Authentik ist ein Open-Source-IdP (Identity Provider), entwickelt von BeryJu unter MIT-Lizenz, geschrieben in Python/Go mit React-Frontend. Es positioniert sich zwischen den schlanken Auth-Proxies wie Authelia und den schwergewichtigen Enterprise-Suiten wie Keycloak.

Was Authentik leistet:

• OIDC-Provider für moderne Web-Apps (Nextcloud, GitLab, Grafana, Vaultwarden)
• SAML2-Provider für Legacy-Anwendungen, die OIDC nicht sprechen
• LDAP-Frontend — Authentik kann sich als LDAP-Server ausgeben, an dem alte Anwendungen authentifizieren
• Proxy-Provider als vorgelagerter Auth-Proxy (ähnlich Authelia/oauth2-proxy) für Dienste ohne eigenes SSO
• MFA: TOTP (Authenticator-Apps), WebAuthn (FIDO2/Passkey), Duo Push, SMS (nicht empfohlen), statische Codes
• Flows: ein visueller Editor, mit dem Login-, Registrierungs- und Recovery-Prozesse konfiguriert werden — von “klassisches Passwort” bis “passwordless mit Magic-Link”
• Outposts: Helper-Container, die Authentik in andere Netze projizieren (z.B. ein Proxy-Outpost in der DMZ)
• Audit-Log und Event-System mit konfigurierbaren Webhooks für SIEM-Integration

Authentik läuft typischerweise als Docker-Compose-Stack oder im Kubernetes-Cluster — Helm-Chart wird offiziell gepflegt.

Authentik vs. Authelia — welches Tool wann?

Beide Tools begegnen sich oft in Diskussionen, lösen aber leicht unterschiedliche Probleme:

Kriterium	Authelia	Authentik
Zielsetzung	schlanker Auth-Proxy mit MFA	vollständiger IdP mit Flows und Lifecycle
Hauptmodus	Forward-Auth vor Reverse-Proxy	OIDC/SAML/LDAP/Proxy frei wählbar
Konfiguration	YAML-Dateien	WebUI mit Flow-Editor
Ressourcenbedarf	minimal (Go-Binary)	mittel (Python/Django + PostgreSQL + Redis)
User-Verwaltung	YAML oder LDAP-Backend	eigene DB mit WebUI, LDAP-Sync möglich
Komplexitäts-Eindruck	Auth-Proxy mit Extras	IdP-Suite
Lerneurve	flach für Forward-Auth	steiler, dafür mehr Möglichkeiten
Typische Zielgruppe	Homelab, kleine Setups	KMU, grössere Homelabs, IdP-Anforderung

Faustregel: Wer einen Auth-Proxy vor einigen Webdiensten braucht und mit YAML-Konfig zufrieden ist, fährt mit Authelia leichter. Wer einen echten Identity-Provider braucht — z.B. weil OIDC-Federation mit Drittanbietern ansteht oder weil das KMU langfristig auf SSO setzt — bekommt mit Authentik mehr Möglichkeiten ohne in Keycloak-Komplexität zu rutschen.

Architektur in einer Übersicht

   Nutzer  ─────►  Reverse-Proxy (nginx/traefik)
                          │
              ┌───────────┴────────────┐
              ▼                        ▼
   Authentik-Server           Service (Nextcloud)
   (OIDC/SAML/Proxy)            │
              │                 │
              ▼                 ▼
        PostgreSQL  ◄───── OIDC-Flow ──────►
        Redis

• Der Nutzer kommt über den Reverse-Proxy auf den Dienst
• Der Dienst leitet zum Authentik-Server zum Login um
• Authentik prüft Credentials + ggf. MFA und schickt einen Token/Assertion zurück
• Der Dienst akzeptiert den Token und gibt den Zugriff frei

Setup: Authentik per Docker Compose

Die offizielle docker-compose.yml lädt Authentik-Server und Worker plus PostgreSQL und Redis. Die wichtigsten Variablen:

# .env (Auszug)
PG_PASS=<starkes-passwort>
AUTHENTIK_SECRET_KEY=<openssl rand -base64 32>
AUTHENTIK_ERROR_REPORTING__ENABLED=false
AUTHENTIK_BOOTSTRAP_PASSWORD=<initialpasswort-akadmin>
AUTHENTIK_BOOTSTRAP_TOKEN=<api-token-initial>

# Hinter eigenem Reverse-Proxy
AUTHENTIK_LISTEN__HTTP=0.0.0.0:9000
AUTHENTIK_LISTEN__HTTPS=0.0.0.0:9443

Nach dem Start wird unter /if/flow/initial-setup/ der akadmin-Account konfiguriert. Danach beginnt die eigentliche Arbeit: Provider und Application für jeden Dienst anlegen.

Beispiel 1: Nextcloud per OIDC

Nextcloud unterstützt OIDC über die App “OpenID Connect Login” oder via “OpenID Connect User Backend”. In Authentik:

1. Provider anlegen: Type “OAuth2/OpenID Provider”, Redirect-URI auf https://cloud.example.com/apps/user_oidc/code
2. Application anlegen: Slug “nextcloud”, Provider verknüpfen
3. Public-Key/Client-ID/Secret notieren

In Nextcloud unter Verwaltung → 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/

Nach erstem Login wird ein Nextcloud-User automatisch angelegt — Quelle der Wahrheit für Existenz und Berechtigung ist ab dann Authentik.

Beispiel 2: GitLab per OIDC

GitLab konfiguriert OIDC über 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"
      }
    }
  }
]

Authentik-seitig wird analog zu Nextcloud ein OAuth2-Provider plus Application angelegt. Nach gitlab-ctl reconfigure zeigt die GitLab-Login-Seite einen “Sign in with Authentik”-Button.

Beispiel 3: Vaultwarden per Proxy-Provider

Vaultwarden hat keinen eigenen SSO-Support — die Vorgabe-Architektur erwartet, dass User direkt anlegt werden. Wer das hinter Authentik bündeln will, nutzt den Proxy-Provider: Authentik fungiert als Forward-Auth vor dem Vaultwarden-Reverse-Proxy. Nur authentifizierte Nutzer kommen überhaupt zur Vaultwarden-Login-Seite.

Vorteil: Die Vaultwarden-Login-Seite ist nicht öffentlich erreichbar und Brute-Force-Angriffe enden bereits an Authentik. Nachteil: zwei Logins (erst Authentik, dann Vaultwarden) — bis Bitwarden/Vaultwarden eigenes SSO mitbringt, ist das die saubere Übergangslösung.

MFA: was wirklich sinnvoll ist

Authentik unterstützt mehrere MFA-Typen. In der Praxis bewährt:

MFA-Typ	Empfehlung
WebAuthn / FIDO2 / Passkey	erste Wahl — Hardware-Token (Yubikey) oder Plattform-Passkey
TOTP (Authenticator-App)	guter Backup, weit verbreitet
Duo Push	wenn Duo eh im Einsatz
Statische Codes	nur als Notfall-Backup, in Tresor speichern
SMS	nicht empfohlen — SIM-Swapping-Risiko

Per Flow kann erzwungen werden, dass MFA spätestens nach erstem Login eingerichtet wird — oder dass für bestimmte Applications (z.B. Vaultwarden, GitLab) MFA Pflicht ist, für andere optional.

Sicherheits-Hinweise

Ein zentraler IdP wird zum Single Point of Failure und zum Single Point of Compromise. Wer Authentik produktiv einsetzt, sollte:

• Authentik selbst hinter MFA stellen — Admin-Login ohne MFA ist tabu
• TLS überall — Authentik niemals plain HTTP
• Backup auf User-Datenbank und Settings: PostgreSQL-Dump regelmässig, Verschlüsselungsschlüssel separat
• Audit-Log überwachen — fehlgeschlagene Admin-Logins, Token-Erstellungen, neue Applications
• Patch-Disziplin: Authentik veröffentlicht regelmässig Releases, Security-Issues werden über das Repo kommuniziert
• Reverse-Proxy mit fail2ban / Rate-Limiting vor Authentik
• Recovery-Plan: was tun, wenn Authentik selbst ausfällt? Mindestens ein lokaler Admin-Account pro Kernsystem für Notfall-Zugriff

Wer den IdP verliert, verliert den Zugriff auf alles. Das ist gleichzeitig das Argument für SSO (Lifecycle-Management) und gegen unbedachtes SSO (Bus-Faktor).

Wann lohnt sich Authentik?

Sinnvoll:

• Mehr als 3-5 Self-Hosted-Dienste mit User-Login
• Mehrere Mitarbeiter mit unterschiedlichen Berechtigungen
• Wechselnde Mitarbeiter (Lifecycle ist sonst ein Albtraum)
• MFA-Pflicht für die ganze Diensteflotte
• Vorbereitung auf zukünftige B2B-Federation (Kunden-Login per OIDC)

Eher Overkill:

• Ein bis zwei Dienste, ein bis zwei Nutzer
• Reines Homelab, das ohne SSO sauber läuft
• Wenn der Aufwand der zentralen Wartung den der dezentralen Userpflege übersteigt

Fazit

Authentik füllt die Lücke zwischen “schlanker Auth-Proxy” (Authelia) und “Enterprise-IdP-Suite” (Keycloak, Okta). Für KMU mit wachsender Self-Hosted-Flotte oder für Homelabs mit ernsthaften Sicherheitsanforderungen ist Authentik der Sweet Spot — vorausgesetzt, der Mehraufwand für die zentrale Verwaltung wird durch die Anzahl der angeschlossenen Dienste gerechtfertigt.

Wer Authentik einführt, sollte mit zwei bis drei Diensten als Pilot starten — z.B. Nextcloud und GitLab — und dann schrittweise weitere Services anbinden. Die Lernkurve ist real, aber gut beherrschbar. Und der Tag, an dem ein Mitarbeiter ausscheidet und der Admin den User in einer einzigen Oberfläche deaktiviert, statt durch sieben Profile zu hangeln, rechtfertigt den Aufwand allein.

Verwandte Artikel

• Vaultwarden: Self-Hosted Passwortmanager
• SSH Hardening: Sichere Fernwartung
• Linux Server Hardening Massnahmen
• Fail2ban: Brute-Force-Schutz