Authentik: Single Sign-On für alle deine Dienste (Teil 1)

Mit jedem neuen Dienst wächst die Liste der Passwörter: Nextcloud, Immich, Grafana, das Wiki – jedes mit eigenen Konten. Authentik dreht das um: ein Konto, eine Anmeldung, zentral verwaltet. Dieser erste Teil baut den Identity-Provider auf und erklärt sein Modell. Teil 2 hängt dann die Dienste daran.

Was bauen wir?

Am Ende läuft Authentik 2026.8.3 hinter deinem Traefik unter https://DEINE_DOMAIN – als eigener Identity-Provider mit PostgreSQL im internen Netz. Du hast ein Administratorkonto, kennst den Aufbau aus Flows, Stages und Providern und kannst Benutzer und Gruppen anlegen.

Zwei Dinge, die viele Anleitungen im Netz noch anders zeigen und die dir Arbeit sparen:

• Redis ist nicht mehr nötig. Aktuelle Authentik-Versionen legen Cache und Websocket-Kanäle in PostgreSQL ab – im Startlog sichtbar als Migrationen django_postgres_cache und django_channels_postgres. Der Stack besteht nur noch aus PostgreSQL, server und worker.
• Der Ressourcenbedarf ist überschaubar. Gemessen im Leerlauf direkt nach der Einrichtung: server 312 MiB, worker 197 MiB, PostgreSQL 42 MiB – zusammen rund 550 MiB RAM. Die oft genannten „mindestens 2 GB" sind eine Empfehlung mit Reserve, kein Startwert.

Warum Authentik – und wann etwas anderes?

Die drei üblichen Kandidaten unterscheiden sich vor allem im Gewicht:

• Authentik bringt eine vollständige Weboberfläche mit Benutzerverwaltung, Gruppen, Ereignisprotokoll und Protokollen von OIDC bis LDAP mit. Das ist viel Funktion – und der Grund, warum es eine Datenbank und einen Worker braucht.
• Authelia ist deutlich leichter, wird über YAML-Dateien konfiguriert und hat keine Benutzerverwaltung im Browser. Wenn du zwei bis drei Dienste absichern willst und Konfiguration gern in Dateien hältst, ist es die schlankere Wahl.
• Keycloak ist das Schwergewicht aus der Java-Welt, mächtig im Unternehmenskontext, aber mit entsprechendem Ressourcen- und Lernaufwand.

Für einen selbst betriebenen Stack mit einer Handvoll Diensten und dem Wunsch, Benutzer im Browser zu verwalten, ist Authentik der beste Kompromiss. Wer nur eine Handvoll statischer Nutzer und keine Lust auf eine Datenbank hat, ist mit Authelia schneller fertig.

Voraussetzungen

• Ein Server mit Debian 13 und Docker (getestet: netcup VPS, Docker 29.6.1, Compose v5.3.1)
• Mindestens 2 GB RAM für den Server insgesamt – Authentik nimmt rund 550 MiB, aber Datenbank-Wartung und Lastspitzen bei vielen Anmeldungen brauchen Luft
• Ein laufender Traefik samt proxy-Netz (Anleitung)
• Eine eigene Subdomain, z. B. auth.DEINE_DOMAIN (Domain verbinden)
• Verständnis von Docker-Netzwerken – wir trennen hier bewusst öffentliches und internes Netz

Schritt für Schritt

1. Verzeichnisse und Geheimnisse anlegen

mkdir -p /opt/authentik/{media,certs,custom-templates} && cd /opt/authentik
chmod 755 media certs custom-templates

Das chmod ist kein Schönheitsfehler. Hast du deinen Server gehärtet und eine strengere umask gesetzt – etwa UMASK 027 in /etc/login.defs, wie sie das Lynis-Audit (Tutorial folgt voraussichtlich im Oktober) empfiehlt –, erzeugt mkdir drwxr-x---. Der Authentik-Container läuft als Benutzer 1000 und kommt in solche Verzeichnisse nicht hinein. Mit chmod 755 funktioniert es unabhängig von der umask:

ohne chmod (drwxr-x---)   /if/flow/initial-setup/  ->  HTTP 500
mit  chmod (drwxr-xr-x)   /if/flow/initial-setup/  ->  HTTP 200

Tückisch daran: Der Gesundheitsendpunkt /-/health/ready/ antwortet in beiden Fällen mit 200. Der Container gilt als gesund, während die Oberfläche nur Fehler ausliefert.

Authentik braucht zwei Geheimnisse: ein Datenbank-Passwort und einen SECRET_KEY, mit dem Sitzungen und Token signiert werden. Beide erzeugst du zufällig und legst sie in eine .env:

{
  echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n=+/')"
  echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')"
} > .env
chmod 600 .env

2. Compose-Datei mit getrennten Netzen

Der Aufbau folgt dem Muster aus Docker-Netzwerke verstehen: Nur der server hängt im öffentlichen proxy-Netz, Datenbank und worker liegen im internen Netz ohne Internetzugang. Lege /opt/authentik/compose.yaml an und ersetze DEINE_DOMAIN:

services:
  postgresql:
    image: postgres:16-alpine
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 20s
    environment:
      POSTGRES_DB: authentik
      POSTGRES_USER: authentik
      POSTGRES_PASSWORD: ${PG_PASS}
    volumes:
      - database:/var/lib/postgresql/data
    networks: [intern]

  server:
    image: ghcr.io/goauthentik/server:2026.8.3
    restart: unless-stopped
    command: server
    depends_on:
      postgresql:
        condition: service_healthy
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_ERROR_REPORTING__ENABLED: "false"
      AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS: 172.16.0.0/12
    volumes:
      - ./media:/media
      - ./custom-templates:/templates
    shm_size: 512mb
    networks: [proxy, intern]
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.authentik.rule=Host(`DEINE_DOMAIN`)"
      - "traefik.http.routers.authentik.entrypoints=websecure"
      - "traefik.http.routers.authentik.tls.certresolver=le"
      - "traefik.http.services.authentik.loadbalancer.server.port=9000"

  worker:
    image: ghcr.io/goauthentik/server:2026.8.3
    restart: unless-stopped
    command: worker
    user: root
    depends_on:
      postgresql:
        condition: service_healthy
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_ERROR_REPORTING__ENABLED: "false"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
      - ./certs:/certs
      - ./custom-templates:/templates
    shm_size: 512mb
    networks: [intern]

volumes:
  database:

networks:
  proxy:
    external: true
  intern:
    internal: true

Vier Punkte, die hier zählen:

• loadbalancer.server.port=9000 – Authentik lauscht intern auf 9000 (HTTP). Der eigene HTTPS-Port 9443 bleibt ungenutzt: TLS macht Traefik.

• shm_size: 512mb stammt aus der offiziellen Referenz und verhindert Speicherfehler bei größeren Datenbankabfragen.

• user: root plus Docker-Socket am worker sind nötig, damit Authentik später eigene „Outposts" als Container verwalten kann. Der Socket ist hier bewusst nicht :ro eingebunden: Authentik muss Container anlegen, beenden und entfernen, und das geht nur mit Schreibzugriff. Wer die Outpost-Verwaltung nicht braucht, lässt den Socket weg.

  Schreibzugriff auf den Docker-Socket ist allerdings faktisch Root auf dem Host. Authentik empfiehlt deshalb selbst, einen Docker-Socket-Proxy davorzusetzen, der nur die nötigen API-Aufrufe durchlässt (Container anlegen, lesen, beenden, entfernen, Version abfragen). Auf einem Server, der mehr tut als Authentik zu betreiben, ist das die Mühe wert.

• AUTHENTIK_ERROR_REPORTING__ENABLED: "false" schaltet die Fehlerübermittlung an das Projekt ab. Standard ist sie aktiv; für datenschutzfreundlichen Betrieb gehört sie aus.

• AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS ist seit 2026.8 Pflicht hinter einem Reverse Proxy. Authentik wertet X-Forwarded-Proto, X-Forwarded-Host und X-Forwarded-For nur noch aus, wenn die Verbindung aus einem hier genannten Netz kommt – das verhindert gefälschte Proxy-Header. Trag das Docker-Netz ein, aus dem Traefik anfragt (Docker vergibt standardmäßig aus 172.16.0.0/12). Fehlt der Eintrag, baut Authentik Weiterleitungen auf http:// statt https:// und die Oberfläche hängt in einer Endlos-Ladeanzeige. Die genaue Adresse deines Traefik findest du mit docker network inspect proxy.

3. Starten und auf die Migrationen warten

cd /opt/authentik && docker compose up -d

Beim ersten Start legt Authentik sein Datenbankschema an – über 70 Migrationen, das dauert. Praktisch prüfbar ist der Fortschritt am Health-Endpunkt:

curl -s -o /dev/null -w "%{http_code}\n" https://DEINE_DOMAIN/-/health/ready/

Solange die Migrationen laufen, antwortet er mit 404; ist Authentik bereit, mit 200. Auf dem VPS 1000 dauerte das zuletzt knapp zwei Minuten. Der Einrichtungs-Flow kommt noch ein paar Sekunden später – der worker spielt erst danach die mitgelieferten Abläufe ein; im Test war er 15 Sekunden nach dem ersten 200 erreichbar. Parallel der Zustand der Container:

docker compose ps --format "{{.Name}}\t{{.Status}}"

authentik-postgresql-1   Up 27 seconds (healthy)
authentik-server-1       Up 21 seconds (health: starting)
authentik-worker-1       Up 21 seconds (healthy)

4. Administratorkonto anlegen

Jetzt der Schritt, an dem viele stolpern: Ruf die Wurzel-Adresse auf, also https://DEINE_DOMAIN/. Von dort leitet Authentik in den Einrichtungs-Flow.

Rufst du den Flow direkt auf (/if/flow/initial-setup/), verweigert Authentik den Dienst mit „Anfrage wurde verweigert – Access the authentik setup by navigating to https://…/". Das ist kein Fehler in deiner Konfiguration, sondern Absicht.

Trag die E-Mail-Adresse und ein sehr langes Passwort ein. Zwei Dinge, die man wissen sollte:

• Der Benutzername des erzeugten Kontos lautet akadmin – nicht deine E-Mail-Adresse.
• Die Oberfläche erscheint in der Sprache deines Browsers; bei einem deutschen Browser also gleich auf Deutsch.

Nach dem Absenden landest du in der Benutzer-Oberfläche (/if/user/) – der Ansicht, die später alle deine Nutzer sehen: eine Kachel-Bibliothek der für sie freigegebenen Anwendungen.

5. Die Administrator-Oberfläche

Die Verwaltung liegt unter https://DEINE_DOMAIN/if/admin/ – oder über den Knopf oben rechts:

Vier Kacheln beantworten die typischen Betriebsfragen:

• System Status – „Alles funktioniert" heißt: Datenbank erreichbar, keine offenen Warnungen.
• Version – die laufende Version. Steht dort „Neueste Version unbekannt", konnte Authentik den Versions-Check nicht durchführen; bei abgeschottetem ausgehendem Verkehr ist das normal.
• Arbeiter – muss mindestens 1 sein. Steht hier 0, läuft der worker nicht, und dann passiert vieles stillschweigend nicht: keine E-Mails, keine Zertifikatsrotation, keine geplanten Aufgaben.
• Letzte Ereignisse – jede Anmeldung und Änderung mit Benutzer, Zeit und Client-IP. Das ist dein Audit-Log und die erste Anlaufstelle bei „wer hat das geändert?".

6. Das Modell verstehen: Flows, Stages, Provider, Anwendungen

Authentik ist kein Login-Formular, sondern ein Baukasten. Wer diese Begriffe kennt, findet sich in der Oberfläche sofort zurecht – und versteht die Fehlermeldungen.

• Stage – ein einzelner Schritt: Passwort abfragen, TOTP-Code prüfen, Zustimmung einholen, Benutzer schreiben. Ein Stage kann nichts allein.
• Flow – eine Kette von Stages für einen Zweck. Authentik bringt fertige mit, sichtbar in der Liste: default-authentication-flow (Anmeldung, 4 Stages), default-invalidation-flow (Abmeldung), default-source-enrollment (Registrierung über eine externe Quelle), dazu Flows zum Einrichten von TOTP und statischen Wiederherstellungscodes.
• Richtlinie (Policy) – eine Bedingung, die entscheidet, ob ein Stage greift oder ein Zugriff erlaubt ist: „nur Mitglieder dieser Gruppe", „nur aus diesem Netz", „nur mit bestätigter E-Mail".
• Provider – die technische Schnittstelle zu einem Dienst: OAuth2/OpenID Connect, SAML, LDAP oder der Proxy-Provider für Anwendungen ohne eigenes Login.
• Anwendung – die Klammer: verbindet einen Provider mit Berechtigungen und erzeugt die Kachel in der Benutzer-Bibliothek.
• Outpost – eine ausgelagerte Komponente, die Authentik selbst betreibt (etwa für den Proxy-Provider). Genau dafür braucht der worker den Docker-Socket.

Für den Alltag heißt das: Die Standard-Flows fasst du nicht an. Du legst pro Dienst einen Provider plus eine Anwendung an – und genau das ist der Inhalt von Teil 2.

Was dabei beim Anmelden tatsächlich passiert, lässt sich an den Standard-Flows ablesen. Ruft ein Benutzer einen geschützten Dienst auf, läuft der default-authentication-flow mit seinen vier Stages:

1. Identifikation – wer bist du? (Benutzername oder E-Mail, je nach Einstellung)
2. Passwort – die Prüfung gegen das gespeicherte Passwort
3. Authenticator-Validierung – gibt es einen zweiten Faktor, wird er hier verlangt
4. Benutzer-Login – die Sitzung wird angelegt

Danach übernimmt der Autorisierungs-Flow: Er entscheidet, ob dieser Benutzer diese Anwendung nutzen darf (default-provider-authorization-explicit-consent fragt einmal um Zustimmung, …-implicit-consent überspringt die Rückfrage). Beim Abmelden greift der Invalidierungs-Flow.

Wenn später etwas nicht klappt, ist genau diese Reihenfolge die Suchhilfe: Bleibt der Nutzer beim Passwort hängen, ist es ein Problem im Authentifizierungs-Flow. Kommt er durch, sieht die Anwendung aber nicht, liegt es an der Autorisierung – also an Berechtigungen oder Richtlinien.

7. Benutzer und Gruppen anlegen

Unter Verzeichnis → Benutzer erzeugst du Konten. Wichtig ist die Trennung:

• Benutzer haben Benutzernamen, Namen, E-Mail und optional Attribute.
• Gruppen bündeln Benutzer – und an Gruppen hängst du später die Berechtigungen für Anwendungen. Lege also gleich Gruppen an (familie, admins), statt jedem Benutzer einzeln Rechte zu geben. Sonst pflegst du bei zehn Diensten zehnmal dieselbe Liste.

Das Konto akadmin nutzt du danach nur noch für Verwaltung; für den Alltag legst du dir ein normales Konto an. Das ist dieselbe Trennung wie „nicht als root arbeiten".

8. Authentik selbst härten

Der Identity-Provider ist ab jetzt das lohnendste Ziel auf deinem Server. Vier Maßnahmen, die zusammen wenig Aufwand kosten:

• Rate-Limit und Security-Header davorschalten. Authentik hat eine eigene Reputationsprüfung, aber die erste Bremse gehört an den Reverse Proxy. Häng die Middlewares aus Traefik härten an den Router – ein Rate-Limit macht Passwort-Raten unattraktiv, bevor die Anfrage Authentik überhaupt erreicht.
• Die Administrationsoberfläche einschränken. /if/admin/ brauchst du selten und selten von unterwegs. Eine IP-Allowlist oder ein Zugang nur über WireGuard ist hier angemessen – ohne den normalen Anmeldeweg für deine Nutzer einzuschränken.
• Zweiten Faktor verpflichtend machen, mindestens für Administratoren. In Authentik hängt das am Authenticator-Validierungs-Stage des Anmelde-Flows.
• Fehlerübermittlung aus lassen – im Compose oben schon gesetzt. Standardmäßig schickt Authentik Fehlerberichte an das Projekt; für einen Dienst, der alle Anmeldedaten deiner Umgebung sieht, gehört das abgeschaltet.

Wenn es nicht funktioniert

Dein Problem ist nicht dabei? Alle Fehlermeldungen durchsuchen →

Wartung & Backups

Updates sind hier Pflichtprogramm. Das Projekt veröffentlicht häufig – in der Reihe 2026.5 kamen mehrere Korrekturversionen innerhalb weniger Wochen. Weil Authentik der Generalschlüssel für alle angebundenen Dienste ist, willst du Sicherheitskorrekturen zeitnah haben:

cd /opt/authentik && docker compose pull && docker compose up -d

Vorher lesen, dann aktualisieren. Authentik nutzt datumsbasierte Versionen (2026.8.3). Zwischen Minor-Versionen (2026.2 → 2026.5) gibt es regelmäßig Umstellungen, die Handarbeit brauchen; die Release-Notes nennen sie ausdrücklich. Springe nie über mehrere Minor-Versionen auf einmal, und mach vorher ein Backup: Die Datenbank wird beim Start migriert, und das ist nicht ohne Weiteres umkehrbar.

Was ins Backup gehört:

• .env – enthält SECRET_KEY und Datenbank-Passwort. Ohne den Schlüssel ist der Rest wertlos.

• Die PostgreSQL-Datenbank – dort stecken Benutzer, Gruppen, Flows, Provider und Anwendungen. Sichere sie nicht als Dateikopie des Volumes, sondern als Dump:

  Terminal

  docker compose exec -T postgresql pg_dump -U authentik authentik \
    | gzip > /opt/backup/authentik-$(date +%F).sql.gz

• media/ – hochgeladene Logos und Symbole. Klein, aber ärgerlich zu rekonstruieren.

Den Dump nimmt dann Restic mit. Warum kein Volume-Kopie: Eine laufende Datenbank kopiert man nicht dateiweise – dabei entstehen inkonsistente Sicherungen, die erst beim Wiederherstellen auffallen.

Den Ausfall mitdenken. Wenn Authentik steht, kommt niemand mehr in die angebundenen Dienste – das ist die Kehrseite von Single Sign-On. Zwei Vorkehrungen kosten wenig: In jedem angebundenen Dienst ein lokales Notfall-Konto behalten, das ohne SSO funktioniert, und Authentik in die Überwachung aufnehmen – am besten mit einem Check auf /-/health/ready/, der genau das prüft, was zählt.

Nutzer und Gruppen aufräumen. Ein Identity-Provider wächst mit: Gäste, alte Konten, Testnutzer. Nimm dir zweimal im Jahr die Benutzerliste vor und deaktiviere, was nicht mehr gebraucht wird – deaktivieren ist besser als löschen, weil sonst die Ereignisprotokolle Lücken bekommen.