Authentik SSO auf Debian 13 — Single Sign-On selbst hosten

Authentik als Self-Hosted Identity Provider auf Debian 13 einrichten: Single Sign-On für Vaultwarden, Gitea, Nextcloud und alle anderen Self-Hosted-Dienste. Modern, sicher und unter deiner Kontrolle

💡 Hinweis: Dieses Tutorial setzt voraus, dass du einen normalen Benutzer mit sudo-Rechten verwendest — wie im Tutorial Debian 13 Server absichern beschrieben. Außerdem solltest du Docker installiert und einen Reverse Proxy mit Nginx eingerichtet haben.

Einleitung — Was ist Authentik?

Wer mehrere Self-Hosted-Dienste betreibt, kennt das Problem: Für Vaultwarden ein Passwort, für Gitea ein anderes, für Nextcloud noch eins. Jeder Dienst hat seine eigene Benutzerverwaltung, seine eigenen Sicherheitsregeln, seine eigene 2FA-Einrichtung. Bei zehn Diensten wird das schnell unübersichtlich — und unsicher.

Authentik löst das Problem mit Single Sign-On (SSO). Ein zentraler Login für alle eure Dienste. Eine Benutzerverwaltung. Eine Stelle, an der ihr 2FA einrichtet, Passwortrichtlinien festlegt und Zugriffe protokolliert. Authentik ist Open Source, modern und einer der besten Identity Provider, den ihr selbst hosten könnt.

Was Authentik kann

OAuth2 / OpenID Connect — Standard-Protokolle, die fast jede moderne App unterstützt
SAML 2.0 — Für Enterprise-Anwendungen
LDAP-Provider — Authentik kann sich gegenüber Apps wie ein LDAP-Server verhalten
Proxy Provider — Schützt Apps, die selbst kein SSO können
MFA / 2FA — TOTP, WebAuthn (Passkeys), Duo, SMS, E-Mail
Social Login — GitHub, Google, Microsoft, Discord etc. als Login-Quelle
User Self-Service — Passwort-Reset, Profil-Verwaltung, MFA selbst aktivieren
Flows & Stages — Frei konfigurierbare Login-Abläufe
Audit-Log — Vollständige Nachverfolgung aller Logins und Aktionen

Authentik vs. Authelia vs. Keycloak

Drei große Player im Self-Hosted-SSO-Bereich. Kurzvergleich:

Feature	Authentik	Authelia	Keycloak
Setup-Komplexität	Mittel	Niedrig	Hoch
Web-UI	Vollwertig	Nur Config-Files	Vollwertig
OAuth2 / OIDC	Ja	Ja	Ja
SAML	Ja	Nein	Ja
LDAP-Provider	Ja	Nein	Ja
Ressourcen-Bedarf	~600 MB RAM	~50 MB RAM	~1.5 GB RAM
Beste Wahl für	Homelab + Enterprise	Minimal-Setup	Enterprise mit AD

Für die meisten Self-Hosted-Setups ist Authentik die beste Balance: Volle Features, aber kein Java-Monstrum wie Keycloak.

In diesem Guide richten wir Authentik von Grund auf ein — von der Installation über den Reverse Proxy bis zum ersten OAuth-Provider für Vaultwarden inklusive 2FA, Backups und Updates.

Voraussetzungen

Bevor wir starten, braucht ihr:

Einen Debian 13 (Trixie) Server — Eingerichtet nach unserem Debian 13 Server-Guide
Docker & Docker Compose installiert — Wie in unserem Docker-Tutorial beschrieben
Nginx als Reverse Proxy — Siehe Nginx Reverse Proxy Tutorial
Mindestens 2 GB RAM (4 GB empfohlen, vor allem mit aktivem Worker)
Eine Domain (z.B. auth.example.com) — für SSL und sauberen Zugriff zwingend nötig
certbot installiert für SSL-Zertifikate

💡 Hinweis: Authentik kann theoretisch auch ohne eigene Domain laufen, aber moderne Browser blockieren viele OAuth-Features ohne HTTPS. Eine Subdomain wie auth.deinedomain.de ist die saubere Lösung.

Firewall-Ports öffnen

Authentik selbst lauscht intern auf Port 9000 (HTTP) und 9443 (HTTPS). Da wir Nginx als Reverse Proxy davor schalten, müssen nach außen nur die Standard-Ports offen sein: <!– Code Block Pro: bash –>

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

Domain & DNS vorbereiten

Erstellt einen A-Record bei eurem DNS-Provider: <!– Code Block Pro: text –>

Typ:   A
Name:  auth
Wert:  EURE-SERVER-IP
TTL:   3600

Typ:   A
Name:  auth
Wert:  EURE-SERVER-IP
TTL:   3600

Wartet ein paar Minuten und prüft die Auflösung: <!– Code Block Pro: bash –>

dig +short auth.example.com

dig +short auth.example.com

Die Ausgabe sollte eure Server-IP sein.

Authentik installieren

Wir installieren Authentik mit dem offiziellen Docker Compose Setup. Das ist der empfohlene Weg und einfacher zu warten als die Bare-Metal-Installation.

Schritt 1: Verzeichnisstruktur anlegen

sudo mkdir -p /opt/authentik
cd /opt/authentik
sudo mkdir -p media certs custom-templates

sudo mkdir -p /opt/authentik
cd /opt/authentik
sudo mkdir -p media certs custom-templates

Schritt 2: Secrets generieren

Authentik braucht zwei zufällige Secrets — eines für die PostgreSQL-Datenbank und eines als App-Secret-Key. Wir generieren beide direkt in eine .env-Datei:

sudo bash -c 'cat > /opt/authentik/.env <<EOF
PG_PASS=$(openssl rand -base64 36 | tr -d "\n")
AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d "\n")
AUTHENTIK_ERROR_REPORTING__ENABLED=false
COMPOSE_PORT_HTTP=9000
COMPOSE_PORT_HTTPS=9443
EOF'
sudo chmod 600 /opt/authentik/.env

sudo bash -c 'cat > /opt/authentik/.env <<EOF
PG_PASS=$(openssl rand -base64 36 | tr -d "\n")
AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d "\n")
AUTHENTIK_ERROR_REPORTING__ENABLED=false
COMPOSE_PORT_HTTP=9000
COMPOSE_PORT_HTTPS=9443
EOF'
sudo chmod 600 /opt/authentik/.env

⚠️ Wichtig: Die .env-Datei enthält Secrets. Stellt sicher, dass sie nur für root lesbar ist (chmod 600). Macht vor jedem weiteren Schritt ein Backup dieser Datei — ohne diese Secrets ist eure Datenbank unbrauchbar.

Schritt 3: docker-compose.yml erstellen

sudo nano /opt/authentik/docker-compose.yml

sudo nano /opt/authentik/docker-compose.yml

Inhalt:

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

  redis:
    image: docker.io/library/redis:alpine
    command: --save 60 1 --loglevel warning
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    volumes:
      - redis:/data

  server:
    image: ghcr.io/goauthentik/server:2025.10
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_ERROR_REPORTING__ENABLED: ${AUTHENTIK_ERROR_REPORTING__ENABLED}
    volumes:
      - ./media:/media
      - ./custom-templates:/templates
    ports:
      - "127.0.0.1:${COMPOSE_PORT_HTTP}:9000"
      - "127.0.0.1:${COMPOSE_PORT_HTTPS}:9443"
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy

  worker:
    image: ghcr.io/goauthentik/server:2025.10
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_ERROR_REPORTING__ENABLED: ${AUTHENTIK_ERROR_REPORTING__ENABLED}
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
      - ./certs:/certs
      - ./custom-templates:/templates
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy

volumes:
  database:
    driver: local
  redis:
    driver: local

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

  redis:
    image: docker.io/library/redis:alpine
    command: --save 60 1 --loglevel warning
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    volumes:
      - redis:/data

  server:
    image: ghcr.io/goauthentik/server:2025.10
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_ERROR_REPORTING__ENABLED: ${AUTHENTIK_ERROR_REPORTING__ENABLED}
    volumes:
      - ./media:/media
      - ./custom-templates:/templates
    ports:
      - "127.0.0.1:${COMPOSE_PORT_HTTP}:9000"
      - "127.0.0.1:${COMPOSE_PORT_HTTPS}:9443"
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy

  worker:
    image: ghcr.io/goauthentik/server:2025.10
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_ERROR_REPORTING__ENABLED: ${AUTHENTIK_ERROR_REPORTING__ENABLED}
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
      - ./certs:/certs
      - ./custom-templates:/templates
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy

volumes:
  database:
    driver: local
  redis:
    driver: local

💡 Hinweis: Wir binden die Ports gezielt nur an 127.0.0.1 — Authentik ist also von außen nicht direkt erreichbar. Nginx wird gleich die Verbindung weiterleiten. Das ist deutlich sicherer als 0.0.0.0.

Schritt 4: Authentik starten

cd /opt/authentik
sudo docker compose up -d

cd /opt/authentik
sudo docker compose up -d

Der erste Start dauert 1-2 Minuten — Authentik initialisiert die Datenbank und führt Migrationen aus. Den Fortschritt könnt ihr live mitlesen:

sudo docker compose logs -f server

sudo docker compose logs -f server

Wenn ihr Booting worker with pid und Listening on TCP address 0.0.0.0:9000 seht, ist Authentik bereit.

Schritt 5: Initial Setup abschließen

Da Port 9000 nur lokal gebunden ist, geht der Setup-Aufruf nicht direkt von außen. Wir empfehlen einen SSH-Tunnel:

ssh -L 9000:127.0.0.1:9000 user@EURE-SERVER-IP

ssh -L 9000:127.0.0.1:9000 user@EURE-SERVER-IP

Danach im Browser auf eurem Rechner:

http://localhost:9000/if/flow/initial-setup/

http://localhost:9000/if/flow/initial-setup/

Beim Initial Setup legt ihr das Passwort für den akadmin-Account fest. Wählt ein sehr starkes Passwort — das ist der Master-Account für alle eure Dienste.

Alternativ könnt ihr auch erst den Nginx-Reverse-Proxy einrichten (nächster Abschnitt) und dann den Initial-Setup-Pfad direkt auf eurer Domain aufrufen.

Reverse Proxy mit Nginx einrichten

Damit Authentik sauber über HTTPS auf eurer Domain erreichbar ist, schalten wir Nginx davor.

Nginx-Konfiguration

sudo nano /etc/nginx/sites-available/auth.example.com

sudo nano /etc/nginx/sites-available/auth.example.com

Inhalt:

server {
    listen 80;
    listen [::]:80;
    server_name auth.example.com;

    # Let's Encrypt validation
    location /.well-known/acme-challenge/ {
        root /var/www/html;
    }

    # Alles andere auf HTTPS umleiten
    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name auth.example.com;

    # SSL-Zertifikate (werden gleich von certbot eingetragen)
    ssl_certificate /etc/letsencrypt/live/auth.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/auth.example.com/privkey.pem;

    # Größere Header für JWT-Tokens erlauben
    proxy_buffers 8 16k;
    proxy_buffer_size 32k;
    client_max_body_size 5M;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;

        # WebSocket-Support für Live-Updates im Admin-Panel
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_redirect off;
        proxy_read_timeout 86400;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name auth.example.com;

    # Let's Encrypt validation
    location /.well-known/acme-challenge/ {
        root /var/www/html;
    }

    # Alles andere auf HTTPS umleiten
    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name auth.example.com;

    # SSL-Zertifikate (werden gleich von certbot eingetragen)
    ssl_certificate /etc/letsencrypt/live/auth.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/auth.example.com/privkey.pem;

    # Größere Header für JWT-Tokens erlauben
    proxy_buffers 8 16k;
    proxy_buffer_size 32k;
    client_max_body_size 5M;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;

        # WebSocket-Support für Live-Updates im Admin-Panel
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_redirect off;
        proxy_read_timeout 86400;
    }
}

Aktiviert die Konfiguration:

sudo ln -s /etc/nginx/sites-available/auth.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

sudo ln -s /etc/nginx/sites-available/auth.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

SSL-Zertifikat mit Let’s Encrypt

sudo certbot --nginx -d auth.example.com

sudo certbot --nginx -d auth.example.com

Folgt dem Wizard. Certbot trägt die Zertifikate automatisch in eure Nginx-Config ein und richtet die automatische Erneuerung ein.

Testet die Erreichbarkeit:

curl -I https://auth.example.com

curl -I https://auth.example.com

Ihr solltet HTTP/2 200 (oder einen Redirect zur Login-Seite) sehen.

✅ Geschafft! Authentik ist jetzt unter https://auth.example.com erreichbar.

Erste Schritte im Admin-Interface

Loggt euch unter https://auth.example.com mit dem akadmin-Account ein. Ihr landet im User-Interface — wechselt oben rechts auf Admin interface.

Dashboard-Übersicht

Applications — Alle Apps, die Authentik kennen sollen
Providers — Die OAuth2/SAML/LDAP-Konfigurationen pro App
Outposts — Externe Authentik-Komponenten (z.B. Embedded Proxy)
Flows & Stages — Login-, Registration- und Recovery-Abläufe
Directory — Benutzer, Gruppen, Federation Sources
System — Zertifikate, Token, Tasks, Settings

Benutzer & Gruppen anlegen

Bevor wir die erste Anwendung anbinden, legen wir mindestens einen normalen Benutzer und eine Gruppe an.

Directory → Groups → Create
- Name: users
- Klickt auf Create
Directory → Users → Create
- Username: euer-username
- Name: euer Vor- und Nachname
- E-Mail: eure-mail@example.com
- Path: users
- Klickt auf Create
Klickt auf den neuen Benutzer → Set password → starkes Passwort vergeben
Im Tab Groups den Benutzer der users-Gruppe zuweisen

💡 Tipp: Verwendet niemals den akadmin-Account für tägliche Logins. Legt euch einen normalen Benutzer an und verwendet akadmin nur für administrative Aufgaben.

E-Mail (SMTP) konfigurieren

Authentik braucht SMTP für Passwort-Reset und Benachrichtigungen. Geht zu System → Settings:

Default email from:  authentik@example.com
SMTP Host:           smtp.example.com
SMTP Port:           587
SMTP Username:       authentik@example.com
SMTP Password:       euer-smtp-passwort
Use TLS:             aktiviert
Use SSL:             deaktiviert

Default email from:  authentik@example.com
SMTP Host:           smtp.example.com
SMTP Port:           587
SMTP Username:       authentik@example.com
SMTP Password:       euer-smtp-passwort
Use TLS:             aktiviert
Use SSL:             deaktiviert

Klickt auf Test connection — wenn keine Fehler kommen, ist SMTP einsatzbereit.

OAuth2/OIDC-Provider erstellen

Jetzt das eigentliche Herzstück: Wir legen einen OAuth2-Provider an, mit dem sich später Apps gegen Authentik authentifizieren.

Schritt 1: Provider anlegen

Applications → Providers → Create
Wählt OAuth2/OpenID Provider
Konfiguration:
- Name: vaultwarden-provider
- Authorization flow: default-provider-authorization-implicit-consent
- Client type: Confidential
- Client ID: Wird automatisch generiert — kopiert ihn später
- Client Secret: Wird automatisch generiert — kopiert ihn später
- Redirect URIs: https://vault.example.com/identity/connect/oidc-signin (anpassen an eure Vaultwarden-Domain)
- Signing Key: authentik Self-signed Certificate
Klickt auf Create

Schritt 2: Application erstellen

Eine Provider ohne Application ist in Authentik nutzlos — die Application macht den Provider sichtbar und zuweisbar.

Applications → Applications → Create
Konfiguration:
- Name: Vaultwarden
- Slug: vaultwarden
- Provider: vaultwarden-provider (eben angelegt)
- Launch URL: https://vault.example.com
Klickt auf Create

Schritt 3: Verbindungsdaten merken

Klickt auf den eben erstellten Provider → Tab Overview. Ihr seht dort die wichtigen URLs:

OpenID Configuration URL:  https://auth.example.com/application/o/vaultwarden/.well-known/openid-configuration
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/
Issuer:                    https://auth.example.com/application/o/vaultwarden/

OpenID Configuration URL:  https://auth.example.com/application/o/vaultwarden/.well-known/openid-configuration
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/
Issuer:                    https://auth.example.com/application/o/vaultwarden/

Diese Werte plus Client ID und Client Secret sind alles, was eure App braucht, um Authentik anzusprechen.

Erstes Anwendungsbeispiel: Vaultwarden mit Authentik

Hier zeigen wir konkret, wie ihr Vaultwarden gegen Authentik authentifizieren lasst.

Provider in Authentik anlegen

Schon erledigt — siehe oben. Falls noch nicht, geht zurück zum Abschnitt OAuth2/OIDC-Provider erstellen.

Vaultwarden konfigurieren

Vaultwarden unterstützt OIDC ab Version 2025.x über die SSO-Funktion. Erweitert eure Vaultwarden docker-compose.yml um folgende Environment Variables:

environment:
  SSO_ENABLED: "true"
  SSO_ONLY: "false"
  SSO_AUTHORITY: "https://auth.example.com/application/o/vaultwarden/"
  SSO_CLIENT_ID: "EURE_CLIENT_ID_AUS_AUTHENTIK"
  SSO_CLIENT_SECRET: "EUER_CLIENT_SECRET_AUS_AUTHENTIK"
  SSO_SCOPES: "email profile openid"

environment:
  SSO_ENABLED: "true"
  SSO_ONLY: "false"
  SSO_AUTHORITY: "https://auth.example.com/application/o/vaultwarden/"
  SSO_CLIENT_ID: "EURE_CLIENT_ID_AUS_AUTHENTIK"
  SSO_CLIENT_SECRET: "EUER_CLIENT_SECRET_AUS_AUTHENTIK"
  SSO_SCOPES: "email profile openid"

Vaultwarden neu starten:

cd /opt/vaultwarden
sudo docker compose up -d

cd /opt/vaultwarden
sudo docker compose up -d

Öffnet https://vault.example.com
Klickt auf Enterprise Single Sign-On
Gebt einen Identifier ein (eure E-Mail oder die Org-ID)
Ihr werdet zu auth.example.com weitergeleitet
Loggt euch dort mit eurem Authentik-User ein
Authentik fragt einmalig nach Zustimmung zur Datenfreigabe
Zurück bei Vaultwarden — eingeloggt!

✅ Geschafft! Eure erste App nutzt Authentik als Login-Quelle. Der gleiche Ablauf funktioniert mit minimalen Anpassungen für Gitea, Nextcloud, Grafana und alle anderen Apps mit OIDC-Support.

Zwei-Faktor-Authentifizierung erzwingen

Ein zentraler Login ist nur dann ein Sicherheitsgewinn, wenn er auch sicher ist. Authentik macht 2FA für alle eure Apps mit einem einzigen Schritt verpflichtend.

MFA-Stages konfigurieren

In Authentik sind Stages die einzelnen Schritte eines Login-Vorgangs. Wir fügen einen MFA-Stage in den Default-Authentication-Flow ein.

Flows & Stages → Stages → Create
Wählt Authenticator Validation Stage
Konfiguration:
- Name: mfa-validation
- Device classes: TOTP, WebAuthn, Static Tokens
- Not configured action: Force the user to configure an authenticator
Klickt auf Create

Authentifizierungs-Flow anpassen

Flows & Stages → Flows
Klickt auf default-authentication-flow
Tab Stage Bindings
Klickt auf Bind existing stage
Wählt mfa-validation
Order: 30 (zwischen Passwort-Eingabe und Login-Abschluss)
Klickt auf Create

Loggt euch ab und versucht erneut, euch einzuloggen — Authentik fordert jetzt zur Einrichtung eines TOTP- oder WebAuthn-Geräts auf, falls noch keins eingerichtet ist.

💡 Tipp: WebAuthn (Passkeys) sind komfortabler und sicherer als TOTP-Codes. Moderne Browser, YubiKeys und sogar Touch ID auf Macs funktionieren damit. Einrichtung dauert 10 Sekunden.

Outpost & Embedded Proxy für Apps ohne OAuth

Manche Apps können kein OAuth — etwa eine reine Static-HTML-Seite oder ein altes PHP-Tool. Hier kommt der Outpost ins Spiel.

Was ist ein Outpost?

Ein Outpost ist eine separate Komponente, die Authentik als Forward-Auth-Proxy vor eine App setzt. Bevor irgendeine HTTP-Anfrage zur App durchkommt, prüft der Outpost, ob ihr eingeloggt seid. Falls nicht, werdet ihr zu Authentik umgeleitet.

Embedded Outpost nutzen

Authentik hat einen Outpost bereits eingebaut — den Embedded Outpost. Den müsst ihr nur konfigurieren.

Applications → Providers → Create
Wählt Proxy Provider
Konfiguration:
- Name: proxy-meinetool
- Authorization flow: default-provider-authorization-implicit-consent
- External host: https://meinetool.example.com
- Internal host: http://localhost:8080 (wo eure App lauscht)
Klickt auf Create
Applications → Applications → Create
- Name: Meine Tool
- Slug: meinetool
- Provider: proxy-meinetool
Klickt auf Create
Applications → Outposts → embedded-outpost öffnen
Tab Applications → fügt eure neue Application hinzu
Update

App ohne native OAuth-Unterstützung absichern

Passt eure Nginx-Config für meinetool.example.com an, sodass jede Anfrage erst durch Authentik läuft:

server {
    listen 443 ssl http2;
    server_name meinetool.example.com;

    ssl_certificate /etc/letsencrypt/live/meinetool.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/meinetool.example.com/privkey.pem;

    # Authentik Auth-Endpoint
    location /outpost.goauthentik.io {
        proxy_pass http://127.0.0.1:9000/outpost.goauthentik.io;
        proxy_set_header Host $host;
        proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
        add_header Set-Cookie $auth_cookie;
        auth_request_set $auth_cookie $upstream_http_set_cookie;
    }

    location / {
        # Auth-Check
        auth_request /outpost.goauthentik.io/auth/nginx;
        error_page 401 = @goauthentik_proxy_signin;
        auth_request_set $auth_cookie $upstream_http_set_cookie;
        add_header Set-Cookie $auth_cookie;

        # Header von Authentik durchreichen
        auth_request_set $authentik_username $upstream_http_x_authentik_username;
        auth_request_set $authentik_email $upstream_http_x_authentik_email;
        proxy_set_header X-authentik-username $authentik_username;
        proxy_set_header X-authentik-email $authentik_email;

        # Eigentliche App
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
    }

    location @goauthentik_proxy_signin {
        internal;
        add_header Set-Cookie $auth_cookie;
        return 302 /outpost.goauthentik.io/start?rd=$request_uri;
    }
}

server {
    listen 443 ssl http2;
    server_name meinetool.example.com;

    ssl_certificate /etc/letsencrypt/live/meinetool.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/meinetool.example.com/privkey.pem;

    # Authentik Auth-Endpoint
    location /outpost.goauthentik.io {
        proxy_pass http://127.0.0.1:9000/outpost.goauthentik.io;
        proxy_set_header Host $host;
        proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
        add_header Set-Cookie $auth_cookie;
        auth_request_set $auth_cookie $upstream_http_set_cookie;
    }

    location / {
        # Auth-Check
        auth_request /outpost.goauthentik.io/auth/nginx;
        error_page 401 = @goauthentik_proxy_signin;
        auth_request_set $auth_cookie $upstream_http_set_cookie;
        add_header Set-Cookie $auth_cookie;

        # Header von Authentik durchreichen
        auth_request_set $authentik_username $upstream_http_x_authentik_username;
        auth_request_set $authentik_email $upstream_http_x_authentik_email;
        proxy_set_header X-authentik-username $authentik_username;
        proxy_set_header X-authentik-email $authentik_email;

        # Eigentliche App
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
    }

    location @goauthentik_proxy_signin {
        internal;
        add_header Set-Cookie $auth_cookie;
        return 302 /outpost.goauthentik.io/start?rd=$request_uri;
    }
}

Nginx neu laden:

sudo nginx -t && sudo systemctl reload nginx

sudo nginx -t && sudo systemctl reload nginx

Jeder Aufruf von meinetool.example.com wird jetzt erst durch Authentik geleitet — auch wenn die App selbst kein SSO kann.

Backups

Authentik speichert alle Daten in PostgreSQL. Ohne Backup → bei Server-Verlust ist euer komplettes SSO-Setup weg.

Was muss gesichert werden?

/opt/authentik/.env — Secrets (zwingend!)
/opt/authentik/docker-compose.yml
/opt/authentik/media/ — Hochgeladene Logos und Custom-CSS
/opt/authentik/certs/ — Eigene Zertifikate
PostgreSQL-Datenbank — Alle Benutzer, Provider, Flows, Logs

Automatisches Backup-Script

Erstellt ein Backup-Script:

sudo nano /usr/local/bin/authentik-backup.sh

sudo nano /usr/local/bin/authentik-backup.sh

Inhalt

#!/bin/bash
set -e

BACKUP_DIR="/var/backups/authentik"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=14

mkdir -p "$BACKUP_DIR"

# PostgreSQL-Dump
docker exec authentik-postgresql-1 pg_dump \
  -U authentik authentik | gzip > "$BACKUP_DIR/db-$TIMESTAMP.sql.gz"

# Config & Files
tar -czf "$BACKUP_DIR/files-$TIMESTAMP.tar.gz" \
  -C /opt/authentik .env docker-compose.yml media certs

# Alte Backups löschen
find "$BACKUP_DIR" -type f -mtime +$RETENTION_DAYS -delete

echo "Backup completed: $TIMESTAMP"

#!/bin/bash
set -e

BACKUP_DIR="/var/backups/authentik"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=14

mkdir -p "$BACKUP_DIR"

# PostgreSQL-Dump
docker exec authentik-postgresql-1 pg_dump \
  -U authentik authentik | gzip > "$BACKUP_DIR/db-$TIMESTAMP.sql.gz"

# Config & Files
tar -czf "$BACKUP_DIR/files-$TIMESTAMP.tar.gz" \
  -C /opt/authentik .env docker-compose.yml media certs

# Alte Backups löschen
find "$BACKUP_DIR" -type f -mtime +$RETENTION_DAYS -delete

echo "Backup completed: $TIMESTAMP"

Ausführbar machen und mit systemd Timer automatisieren — wie in unserem restic Backup-Tutorial beschrieben:

sudo chmod +x /usr/local/bin/authentik-backup.sh
sudo /usr/local/bin/authentik-backup.sh
ls -lh /var/backups/authentik/

sudo chmod +x /usr/local/bin/authentik-backup.sh
sudo /usr/local/bin/authentik-backup.sh
ls -lh /var/backups/authentik/

Für Off-Site-Backups schickt ihr $BACKUP_DIR zusätzlich mit restic an einen B2/S3-Bucket.

⚠️ Best Practice: Testet eure Backups regelmäßig! Spielt mindestens einmal im Quartal ein Backup auf einem Test-System ein und prüft, ob ihr euch einloggen könnt.

Updates

Authentik veröffentlicht alle 1-2 Monate ein neues Release. Updates sind in der Regel unproblematisch, aber Major-Versionen können Breaking Changes haben.

Update durchführe

cd /opt/authentik

# Image-Tag in docker-compose.yml anpassen (z.B. von 2025.10 auf 2025.12)
sudo nano docker-compose.yml

# Backup vor dem Update!
sudo /usr/local/bin/authentik-backup.sh

# Update
sudo docker compose pull
sudo docker compose up -d

cd /opt/authentik

# Image-Tag in docker-compose.yml anpassen (z.B. von 2025.10 auf 2025.12)
sudo nano docker-compose.yml

# Backup vor dem Update!
sudo /usr/local/bin/authentik-backup.sh

# Update
sudo docker compose pull
sudo docker compose up -d

Während der Migration ist Authentik kurz nicht erreichbar (meist 30-60 Sekunden).

Versionshinweise prüfen

Vor jedem Update: Lest die offiziellen Release Notes. Bei Major-Versionen (z.B. von 2024.x auf 2025.x) gibt es manchmal Migrationen, die manuelle Aktionen erfordern

💡 Empfehlung: Pinnt die Version in der docker-compose.yml (also nicht :latest verwenden). So habt ihr volle Kontrolle, wann ihr aktualisiert.

Zusammenfassung & Checkliste

Hier eine Checkliste, damit ihr nichts vergesst:

Schritt	Status
Debian 13 Server eingerichtet	☐
Docker installiert	☐
Nginx als Reverse Proxy installiert	☐
Domain & DNS-Eintrag konfiguriert	☐
`.env`-Datei mit Secrets erstellt und gesichert	☐
Authentik via Docker Compose gestartet	☐
Initial Setup mit `akadmin`-Passwort abgeschlossen	☐
Nginx Reverse Proxy konfiguriert	☐
SSL-Zertifikat eingerichtet	☐
Normaler Benutzer angelegt	☐
SMTP konfiguriert	☐
Erster OAuth2-Provider angelegt	☐
Erste App (z.B. Vaultwarden) angebunden	☐
MFA / 2FA erzwungen	☐
Backup-Script eingerichtet	☐
Backup einmal manuell getestet	☐

Troubleshooting

Authentik startet nicht

cd /opt/authentik
sudo docker compose logs -f server
sudo docker compose logs -f worker

cd /opt/authentik
sudo docker compose logs -f server
sudo docker compose logs -f worker

Häufigste Ursachen:

.env-Datei fehlt oder ist fehlerhaft
PostgreSQL-Container ist nicht healthy → sudo docker compose ps prüfen
Speicherplatz voll → df -h

Meist ein Problem mit dem Reverse Proxy. Prüft:

Setzt Nginx den Host-Header korrekt? (siehe Config oben)
Funktioniert curl http://127.0.0.1:9000 direkt auf dem Server?
Worker-Logs prüfen: sudo docker compose logs -f worker

E-Mail-Versand funktioniert nicht

SMTP-Settings korrekt? System → Settings → Test Connection
Firewall blockiert ausgehenden Port 587? sudo ufw status
SMTP-Provider erlaubt euren Server? (manche Provider blockieren VPS-IPs)

OAuth-Redirect schlägt fehl

Stimmt die Redirect URI im Provider exakt mit dem überein, was die App nutzt?
HTTPS-Zwang: Authentik akzeptiert in Production keine http://-Redirects
Worker-Logs prüfen — dort steht der erwartete vs. tatsächliche Wert

Klassisches Reverse-Proxy-Problem. Prüft in der Nginx-Config:

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;

Beide Header müssen gesetzt sein. Außerdem darf Authentik nicht über http:// aufgerufen werden, sobald HTTPS aktiv ist.

Nächste Schritte

Authentik läuft — und jetzt? Hier sind sinnvolle nächste Schritte:

Mehr Apps anbinden — Gitea, Nextcloud, Grafana, Portainer, Uptime Kuma — fast alle modernen Tools sprechen OIDC
LDAP-Provider einrichten — Falls ihr Tools habt, die nur LDAP, aber kein OIDC können
Federation einrichten — GitHub-Login, Google-Login als Quelle für eure Authentik-User
Custom Branding — Eigene Logos, Farben und CSS für eure Login-Seite
Audit-Log auswerten — Events zeigt jeden Login-Versuch — perfekt für Security-Reviews
Geo-Block / Risk-based Auth — Per Policy lassen sich Logins aus bestimmten Ländern blockieren

Authentik ist eines der mächtigsten Open-Source-Tools im Self-Hosted-Bereich. Die offizielle Dokumentation ist hervorragend und wird sehr aktiv gepflegt.

Habt ihr Fragen oder Probleme? Schreibt es in die Kommentare — ich helfe gerne!