Was bauen wir?

Wir binden zwei Dienste an, jeweils auf dem passenden Weg:

• Forward-Auth für eine Anwendung ohne eigene Anmeldung. Traefik fragt vor jeder Anfrage bei Authentik nach, ob der Besucher angemeldet ist. Ist er es nicht, landet er auf der Authentik-Anmeldeseite; ist er es, bekommt die Anwendung seine Identität als HTTP-Header.
• OpenID Connect (OIDC) für Anwendungen mit SSO-Unterstützung – Grafana, Nextcloud, Forgejo, Immich und viele andere. Dort trägst du Client-ID, Secret und die Endpunkte ein, den Rest macht die App selbst.

Alles unten wurde mit Authentik 2026.8 hinter Traefik v3.7 auf Debian 13 durchgespielt: Am Ende zeigt der Testdienst die durchgereichten Identitäts-Header, und das OIDC-Discovery-Dokument liefert echte Endpunkte.

Welcher Weg für welchen Dienst?

Die Entscheidung ist fast immer eindeutig:

Kurz: OIDC, wo möglich; Forward-Auth, wo nötig. OIDC gibt der Anwendung ein echtes Benutzerkonto inklusive Rollen; Forward-Auth stellt nur eine Tür davor und schiebt einen Namen im Header durch.

Voraussetzungen

• Ein laufendes Authentik aus Teil 1, erreichbar unter https://DEINE_DOMAIN
• Ein Traefik v3 mit proxy-Netz (Anleitung) – wir arbeiten hier viel mit Middlewares, die Grundlagen dazu stehen in Traefik härten
• Ein Dienst zum Üben. Wir nehmen traefik/whoami, weil er alle empfangenen Header ausgibt – damit ist sofort sichtbar, ob die Anbindung wirklich greift

Schritt für Schritt

1. Zugang für die Automatisierung: ein API-Token

Provider und Anwendungen lassen sich vollständig über die API anlegen – praktisch, weil du damit reproduzierbar arbeitest statt zu klicken. Dafür braucht Authentik einen Token.

Weil du in Teil 1 den Einrichtungsassistenten durchlaufen hast, existiert akadmin bereits. Den Token legst du deshalb in der Oberfläche an: Verzeichnis → Tokens und App-Passwörter → Token erstellen. Als Bezeichner nimm etwas Sprechendes (api-setup), als Absicht API, als Benutzer akadmin. Nach dem Speichern kopierst du den Schlüssel über das Kopiersymbol – er wird nur einmal angezeigt.

docker compose run --rm server hash_password

  worker:
    environment:
      AUTHENTIK_BOOTSTRAP_PASSWORD_HASH: ${AK_BOOTSTRAP_PASSWORD_HASH}
      AUTHENTIK_BOOTSTRAP_TOKEN: ${AK_BOOTSTRAP_TOKEN}
      AUTHENTIK_BOOTSTRAP_EMAIL: du@DEINE_DOMAIN

Prüfe den Token – egal auf welchem Weg er entstanden ist:

curl -s -H "Authorization: Bearer DEIN_LANGER_ZUFALLS_TOKEN" \
  https://DEINE_DOMAIN/api/v3/core/users/me/

{"user":{"username":"akadmin", … "is_superuser":true, …}}

2. Weg A: Forward-Auth für Dienste ohne Login

Der Proxy-Provider ist Authentiks Antwort auf „diese App hat gar keine Benutzerverwaltung". Er kommt in mehreren Betriebsarten; wir nehmen forward_single: eine Anwendung, ein Provider.

Zuerst die IDs der beiden Standard-Flows (aus Teil 1 bekannt):

API=https://DEINE_DOMAIN/api/v3
TOK="Authorization: Bearer DEIN_LANGER_ZUFALLS_TOKEN"

AUTHZ=$(curl -s -H "$TOK" "$API/flows/instances/?slug=default-provider-authorization-implicit-consent" \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['results'][0]['pk'])")
INVAL=$(curl -s -H "$TOK" "$API/flows/instances/?slug=default-provider-invalidation-flow" \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['results'][0]['pk'])")

Dann den Provider:

curl -s -X POST -H "$TOK" -H "content-type: application/json" "$API/providers/proxy/" -d "{
  \"name\": \"whoami-forwardauth\",
  \"authorization_flow\": \"$AUTHZ\",
  \"invalidation_flow\": \"$INVAL\",
  \"mode\": \"forward_single\",
  \"external_host\": \"https://DEINE_DOMAIN\"
}"

Und die Anwendung, die ihn benutzt – sie erzeugt auch die Kachel in der Benutzer-Bibliothek:

curl -s -X POST -H "$TOK" -H "content-type: application/json" "$API/core/applications/" -d '{
  "name": "whoami (geschützt)", "slug": "whoami", "provider": 1
}'

Die 1 ist die pk aus der Antwort des Provider-Aufrufs. Danach stehen beide in der Übersicht:

3. Den Outpost scharf schalten – und die häufigste Falle

Ein Proxy-Provider arbeitet nicht allein: Ein Outpost liefert ihn aus. Authentik bringt einen eingebetteten Outpost mit, der im server-Container läuft – du musst ihm den Provider nur zuweisen:

OUT=$(curl -s -H "$TOK" "$API/outposts/instances/" \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['results'][0]['pk'])")
curl -s -X PATCH -H "$TOK" -H "content-type: application/json" \
  "$API/outposts/instances/$OUT/" -d '{"providers": [1]}'

curl -s -X PATCH -H "$TOK" -H "content-type: application/json" \
  "$API/outposts/instances/$OUT/" \
  -d '{"config": {"authentik_host": "https://DEINE_DOMAIN/"}}'

4. Traefik: die Forward-Auth-Middleware

Jetzt fehlt die Verbindung. Traefik fragt vor jeder Anfrage beim Outpost nach – das macht die Middleware forwardauth. Am geschützten Dienst:

  whoami:
    image: traefik/whoami:v1.12
    restart: unless-stopped
    networks: [proxy]
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`DEINE_DOMAIN`) && PathPrefix(`/whoami`)"
      - "traefik.http.routers.whoami.entrypoints=websecure"
      - "traefik.http.routers.whoami.tls.certresolver=le"
      - "traefik.http.routers.whoami.middlewares=ak-auth"
      - "traefik.http.services.whoami.loadbalancer.server.port=80"
      - "traefik.http.middlewares.ak-auth.forwardauth.address=http://server:9000/outpost.goauthentik.io/auth/traefik"
      - "traefik.http.middlewares.ak-auth.forwardauth.trustForwardHeader=true"
      - "traefik.http.middlewares.ak-auth.forwardauth.authResponseHeaders=X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid"

Die drei entscheidenden Zeilen:

• address zeigt auf den Outpost – hier über den Container-Namen server im gemeinsamen Docker-Netz, also ohne Umweg über das Internet. Der Pfad /outpost.goauthentik.io/auth/traefik ist der Traefik-spezifische Prüf-Endpunkt.
• trustForwardHeader=true gibt die X-Forwarded-*-Header weiter, damit Authentik die ursprünglich aufgerufene Adresse kennt und korrekt zurückleiten kann.
• authResponseHeaders ist der eigentliche Nutzen: Diese Header kopiert Traefik aus der Antwort von Authentik in die Anfrage an deine Anwendung. Fehlt die Zeile, ist der Dienst geschützt, weiß aber nicht, wer da ist.

5. Prüfen, dass es wirklich schützt

Erst ohne Anmeldung – dafür reicht curl:

curl -s -o /dev/null -w "%{http_code} → %{redirect_url}\n" https://DEINE_DOMAIN/whoami

302 → https://DEINE_DOMAIN/application/o/authorize/?client_id=…&redirect_uri=…%2Foutpost.goauthentik.io%2Fcallback…

Ein 302 auf die Authentik-Anmeldung ist das gewünschte Ergebnis. Im Browser erscheint die Anmeldeseite vor dem Dienst:

Nach der Anmeldung landest du wieder auf /whoami – und der Dienst zeigt, was bei ihm ankommt:

GET /whoami HTTP/1.1
Host: DEINE_DOMAIN
X-Authentik-Email: du@DEINE_DOMAIN
X-Authentik-Groups: authentik Admins
X-Authentik-Name: authentik Default Admin
X-Authentik-Uid: d216e191a6f972c39931a005a7998a68…
X-Authentik-Username: akadmin
X-Forwarded-Proto: https

Das ist der ganze Trick: Die Anwendung hat keine Zeile Anmeldecode – und weiß trotzdem, wer vor ihr sitzt. Dienste, die Header-Authentifizierung unterstützen (Grafana mit auth.proxy, Paperless, Forgejo mit Reverse-Proxy-Auth), können daraus direkt eine Sitzung machen.

6. Die Grenzen von Forward-Auth kennen

Bevor du alles hinter Forward-Auth hängst: Der Mechanismus setzt einen Browser voraus. Eine nicht angemeldete Anfrage bekommt eine 302-Weiterleitung auf ein Anmeldeformular – und genau daran scheitert alles, was kein Browser ist:

• Mobil-Apps (Nextcloud, Immich, Audiobookshelf) können mit der Weiterleitung nichts anfangen. Sie sehen HTML statt JSON und melden „Server nicht erreichbar". Für solche Dienste ist OIDC der einzige sinnvolle Weg – oder du nimmst die App-Pfade gezielt aus.
• API-Zugriffe und Skripte (curl, Backup-Jobs, Webhooks) laufen ins Leere. Wo ein Dienst per Token angesprochen wird, muss dieser Pfad an der Middleware vorbei – oder du verlagerst den Schutz auf eine IP-Allowlist.
• WebDAV und Sync-Clients verhalten sich wie APIs, mit demselben Ergebnis.

Für solche Ausnahmen legst du einen zweiten Router ohne die Auth-Middleware an, der nur den nötigen Pfad bedient – und schützt ihn anders, etwa mit dem Token der Anwendung selbst. Beispiel für einen API-Pfad:

      - "traefik.http.routers.app-api.rule=Host(`DEINE_DOMAIN`) && PathPrefix(`/api`)"
      - "traefik.http.routers.app-api.entrypoints=websecure"
      - "traefik.http.routers.app-api.tls.certresolver=le"
      - "traefik.http.routers.app-api.middlewares=rate@file"

Zur Vollständigkeit die dritte Betriebsart des Proxy-Providers: forward_domain. Damit bedient ein Outpost alle Dienste einer Domain (*.DEINE_DOMAIN), und Nutzer melden sich einmal für alle an. Das ist der bequemere Aufbau ab etwa drei Diensten, verlangt aber, dass Authentik und alle Anwendungen unter derselben übergeordneten Domain liegen, damit das Sitzungs-Cookie geteilt werden kann. Hier getestet ist forward_single – die Umstellung betrifft nur den Modus im Provider und die Cookie-Domain.

7. Weg B: OpenID Connect für Dienste mit eigenem SSO

Hat die Anwendung eine OIDC-Anmeldung, ist das der bessere Weg: Sie führt dann echte Benutzerkonten inklusive Rollen, statt nur einen Namen im Header zu sehen.

Provider anlegen – wichtig ist die Redirect-URI, die genau der Rückadresse der Anwendung entsprechen muss (Beispiel Grafana):

curl -s -X POST -H "$TOK" -H "content-type: application/json" "$API/providers/oauth2/" -d "{
  \"name\": \"grafana-oidc\",
  \"authorization_flow\": \"$AUTHZ\",
  \"invalidation_flow\": \"$INVAL\",
  \"client_type\": \"confidential\",
  \"redirect_uris\": [{\"matching_mode\": \"strict\", \"url\": \"https://GRAFANA_DOMAIN/login/generic_oauth\"}]
}"

Die Antwort enthält client_id und client_secret – beide brauchst du in der Anwendung. Danach wie oben eine Anwendung anlegen, die auf diesen Provider zeigt.

Ob alles sitzt, verrät das Discovery-Dokument. Authentik veröffentlicht es pro Anwendung unter deren Slug:

curl -s https://DEINE_DOMAIN/application/o/grafana/.well-known/openid-configuration \
  | python3 -m json.tool | head -12

"issuer": "https://DEINE_DOMAIN/application/o/grafana/",
"authorization_endpoint": "https://DEINE_DOMAIN/application/o/authorize/",
"token_endpoint": "https://DEINE_DOMAIN/application/o/token/",
"userinfo_endpoint": "https://DEINE_DOMAIN/application/o/userinfo/",

Beachte: Der Issuer ist anwendungsspezifisch (er enthält den Slug), die übrigen Endpunkte sind für alle Anwendungen gleich. Genau diese Adressen – oder die Discovery-URL selbst, wenn die App sie unterstützt – trägst du in der Anwendung ein. Für Grafana etwa:

GF_AUTH_GENERIC_OAUTH_ENABLED=true
GF_AUTH_GENERIC_OAUTH_NAME=Authentik
GF_AUTH_GENERIC_OAUTH_CLIENT_ID=DEINE_CLIENT_ID
GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET=DEIN_CLIENT_SECRET
GF_AUTH_GENERIC_OAUTH_SCOPES=openid profile email
GF_AUTH_GENERIC_OAUTH_AUTH_URL=https://DEINE_DOMAIN/application/o/authorize/
GF_AUTH_GENERIC_OAUTH_TOKEN_URL=https://DEINE_DOMAIN/application/o/token/
GF_AUTH_GENERIC_OAUTH_API_URL=https://DEINE_DOMAIN/application/o/userinfo/

8. Wer darf was? Zugriff einschränken

Solange an einer Anwendung keine Richtlinie hängt, darf sie jeder angemeldete Benutzer nutzen. Für den Regelfall bindest du eine Gruppe an die Anwendung: Anwendungen → deine Anwendung → Richtlinien / Gruppen / Benutzer-Bindungen, dort die Gruppe auswählen.

Erst danach verschwindet die Kachel in der Benutzer-Bibliothek für alle anderen – und der Zugriff ist gesperrt. Prüfen lässt sich das am ehrlichsten mit einem zweiten Testkonto, das nicht in der Gruppe ist: Es soll die Anwendung weder sehen noch aufrufen können.

Wenn es nicht funktioniert

Dein Problem ist nicht dabei? Alle Fehlermeldungen durchsuchen →

Wartung & Backups

Nach jedem Authentik-Update stichprobenartig prüfen. Ein Update kann Flows und Provider verändern; die Anbindungen selbst sind robust, aber der schnelle Test lohnt: curl auf den geschützten Pfad muss weiterhin 302 liefern, und das Discovery-Dokument muss deine Endpunkte zeigen. Zwei Kommandos, die verhindern, dass eine Anmeldung wochenlang unbemerkt kaputt ist.

Client-Secrets gehören in den Passwortmanager. Sie stehen in der Anwendung (Umgebungsvariablen) und in Authentik. Wird eines neu erzeugt, muss die andere Seite mitgezogen werden – notiere beim Anlegen, welche App welches Secret nutzt, sonst suchst du später in beiden Systemen.

Die Datenbank ist jetzt noch wichtiger. Provider, Anwendungen und Gruppen-Bindungen liegen alle in PostgreSQL. Der pg_dump aus Teil 1 ist damit kein Nice-to-have mehr: Ohne ihn baust du nach einem Ausfall jede Anbindung neu. Mit Restic täglich wegsichern.

Den Notausgang offen halten. Jeder Dienst hinter Forward-Auth ist nur so erreichbar wie Authentik. Behalte in wichtigen Anwendungen ein lokales Konto – und häng keine Werkzeuge hinter SSO, die du zur Reparatur brauchst; das gilt besonders für Dockge und ähnliche Verwaltungsoberflächen. Ein Monitoring auf /-/health/ready/ merkt den Ausfall vor deinen Nutzern.

Tokens aufräumen. Der Bootstrap-Token aus Schritt 1 ist ein Admin-Zugang ohne zweiten Faktor. Wenn die Einrichtung steht, lösch ihn unter Verzeichnis → Tokens – und leg für spätere Automatisierung einen eigenen Token mit begrenzten Rechten an.

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.