Authelia mit Reverse Proxy und 2FA

Authelia ist eine starke Lösung, wenn du Self-Hosted-Anwendungen mit zentraler Anmeldung und zusätzlicher Zwei-Faktor-Authentifizierung absichern willst. Statt jede App einzeln mit einem eigenen Login- und 2FA-System auszustatten, kannst du den Zugriff zentral vor dem Reverse Proxy kontrollieren.

Gerade für Admin-Panels, interne Tools, Dashboards, File-Services oder andere sensible Webanwendungen ist das ein großer Sicherheitsgewinn. Die aktuelle Authelia-Dokumentation empfiehlt für neue Setups den modernen Session-Block mit session.cookies und je nach Proxy eine passende Integration, zum Beispiel über auth_request bei Nginx.

In dieser Anleitung richten wir Authelia auf Ubuntu per Docker Compose ein, verwenden zum Einstieg die Dateibasis für Benutzer, aktivieren TOTP-2FA und schützen anschließend eine Beispiel-Anwendung hinter Nginx.

1. Voraussetzungen

Bevor du loslegst, solltest du Folgendes bereit haben:

• einen Ubuntu Server mit Docker und Docker Compose Plugin
• einen funktionierenden Reverse Proxy, zum Beispiel Nginx
• eine Domain wie example.com mit passenden DNS-Einträgen
• eine separate Subdomain für Authelia, zum Beispiel https://auth.example.com
• eine Zielanwendung, die du schützen möchtest, zum Beispiel https://app.example.com

Wichtig: Authelia wird nicht direkt „anstelle“ deiner App eingebunden, sondern sitzt logisch davor. Dein Reverse Proxy fragt Authelia, ob ein Benutzer auf die Zielanwendung zugreifen darf.

2. Arbeitsverzeichnis anlegen

Lege zuerst ein sauberes Verzeichnis für das Setup an:

mkdir -p ~/authelia/config
cd ~/authelia

Darin speichern wir gleich Compose-Datei, Konfiguration und Benutzerdaten.

3. Passwörter und Secrets erzeugen

Authelia braucht mehrere geheime Werte, unter anderem für Session-Schutz und Speicherverschlüsselung. Erzeuge dir dafür zufällige Strings, zum Beispiel mit OpenSSL:

openssl rand -hex 32
openssl rand -hex 32
openssl rand -hex 32

Du brauchst diese Werte später unter anderem für:

• jwt_secret
• session.secret
• storage.encryption_key

Verwende hier wirklich starke Zufallswerte und keine Platzhalter aus Beispielen.

4. Passwort-Hash für den ersten Benutzer erzeugen

Für den Einstieg mit Datei-Backend brauchst du einen Passwort-Hash für deinen Benutzer. Das kannst du bequem im offiziellen Container erzeugen:

docker run --rm authelia/authelia:latest authelia crypto hash generate argon2 --password 'DEIN_SICHERES_PASSWORT'

Kopiere dir den ausgegebenen Hash. Den tragen wir gleich in die Benutzerdatei ein.

5. Benutzerdatei erstellen

Lege jetzt die Datei config/users_database.yml an:

users:
  admin:
    displayname: "Admin"
    password: "$argon2id$v=19$m=65536,t=3,p=4$..."
    email: "admin@example.com"
    groups:
      - admins

Ersetze den Passwort-Hash natürlich durch deinen echten Wert und passe die E-Mail-Adresse an.

6. Authelia Konfiguration anlegen

Authelia erzeugt beim ersten Start eine Version der Konfiguration als Template. Für ein bewusst schlankes Einstiegsszenario kannst du aber direkt mit einer eigenen config/configuration.yml starten.

Ein solider Basisaufbau sieht zum Beispiel so aus:

theme: auto

server:
  address: 'tcp://0.0.0.0:9091'
  endpoints:
    authz:
      auth-request:
        implementation: 'AuthRequest'

log:
  level: info

identity_validation:
  reset_password:
    jwt_secret: 'ERSETZE_DURCH_EIN_STARKES_SECRET'

totp:
  issuer: 'example.com'

authentication_backend:
  file:
    path: /config/users_database.yml

access_control:
  default_policy: deny
  rules:
    - domain: 'app.example.com'
      policy: two_factor

session:
  secret: 'ERSETZE_DURCH_EIN_STARKES_SECRET'
  cookies:
    - domain: 'example.com'
      authelia_url: 'https://auth.example.com'
      default_redirection_url: 'https://app.example.com'

storage:
  encryption_key: 'ERSETZE_DURCH_EIN_STARKES_SECRET'
  local:
    path: /config/db.sqlite3

notifier:
  filesystem:
    filename: /config/notification.txt

Wichtige Punkte dabei:

• die Session-Konfiguration nutzt bereits das moderne session.cookies-Format
• die geschützte Anwendung app.example.com wird auf two_factor gesetzt
• für den Einstieg reicht das lokale Datei- und SQLite-Backend völlig aus

7. Docker Compose Datei erstellen

Lege jetzt eine docker-compose.yml an:

services:
  authelia:
    image: authelia/authelia:latest
    container_name: authelia
    restart: unless-stopped
    volumes:
      - ./config:/config
    ports:
      - "9091:9091"

Das reicht für den Einstieg bereits aus. Authelia lauscht danach lokal auf Port 9091.

8. Authelia starten und Logs prüfen

Starte den Container:

docker compose up -d

Prüfe direkt danach die Logs:

docker compose logs -f authelia

Gerade bei YAML-Einrückungen, fehlenden Secrets oder Tippfehlern im Session-Block meldet Authelia sehr klar, was nicht stimmt.

9. Authelia Portal über den Reverse Proxy veröffentlichen

Authelia selbst sollte sauber über deine dedizierte Subdomain erreichbar sein, zum Beispiel:

https://auth.example.com

Dein Reverse Proxy leitet dabei auf den lokalen Authelia-Dienst weiter, also meist auf http://127.0.0.1:9091 oder auf den passenden Docker-Namen in deinem Proxy-Netz.

Wichtig ist, dass du für die Portal-Domain saubere Forwarded Headers und Real-IP-Informationen setzt, damit Authelia Client-IP und Weiterleitungen korrekt behandeln kann.

10. Eine Beispiel-App mit Nginx schützen

Die offizielle Authelia-Doku nutzt bei Nginx die auth_request-Integration. Ein minimales Beispiel für eine geschützte Anwendung könnte so aussehen:

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

    location /authelia {
        internal;
        proxy_pass http://127.0.0.1:9091/api/authz/auth-request;
        proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Uri $request_uri;
        proxy_set_header X-Forwarded-Method $request_method;
        proxy_set_header Content-Length "";
        proxy_pass_request_body off;
    }

    location / {
        auth_request /authelia;
        error_page 401 =302 https://auth.example.com/?rd=https://app.example.com;

        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Wichtig: Die Authelia-Dokumentation weist ausdrücklich darauf hin, dass die Beispiele angepasst werden müssen. Gerade bei Trusted Proxies, Container-Namen, Proxy-Netzen und Headern solltest du dein echtes Setup berücksichtigen.

11. Zugriff testen

Wenn alles passt, sollte beim Aufruf von

https://app.example.com

zuerst die Authelia-Anmeldung erscheinen. Nach erfolgreichem Login gelangst du erst dann zur geschützten Anwendung.

Wenn die Weiterleitung nicht korrekt funktioniert, prüfe zuerst:

• stimmt authelia_url in der Session-Konfiguration?
• stimmt die geschützte Domain in access_control.rules?
• reichen die Nginx-Header korrekt an Authelia durch?
• ist der Redirect auf das Portal richtig gesetzt?

12. TOTP als Zwei-Faktor-Authentifizierung einrichten

Authelia unterstützt TOTP als klassische App-basierte Zwei-Faktor-Authentifizierung. Laut aktueller Doku sind die Standardwerte bewusst auf hohe Kompatibilität ausgelegt, und genau dabei würde ich es zunächst auch belassen.

Wenn du die oben gezeigte Konfiguration mit dem totp-Block verwendest, kannst du dich nach dem ersten Login zur Registrierung eines TOTP-Geräts führen lassen. Typische Apps dafür sind:

• Aegis
• Google Authenticator
• 2FAS
• Authy

Scanne den QR-Code mit deiner Authenticator-App und bestätige anschließend den generierten Code. Danach ist für die definierte Zielanwendung die Richtlinie two_factor aktiv.

13. Was du danach als Nächstes verbessern kannst

Das oben gezeigte Setup ist ein guter und praxistauglicher Einstieg. Danach kannst du Authelia weiter ausbauen, zum Beispiel mit:

• echtem SMTP-Notifier statt Dateibenachrichtigung
• LDAP oder anderen Identitätsquellen
• mehreren Access-Control-Regeln für verschiedene Apps
• strengeren Policies für besonders sensible Dienste
• besserem Secret-Management über Umgebungsvariablen oder Docker Secrets

14. Typische Fehler vermeiden

Diese Dinge führen bei Authelia-Setups besonders oft zu Frust:

• Session-Domain passt nicht zur echten Domainstruktur
• Authelia-Portal und Ziel-App liegen auf unpassenden Domains
• Forwarded Headers fehlen oder sind falsch
• Beispiele aus der Doku werden 1:1 kopiert, ohne das eigene Proxy-Setup zu berücksichtigen
• zu schwache oder wiederverwendete Secrets

Gerade bei Reverse-Proxys lohnt es sich, die Proxy-Integration wirklich aufmerksam zu lesen und nicht nur blind ein Snippet zu übernehmen.

15. Fazit

Authelia ist ein sehr starker Baustein, wenn du deine Self-Hosted-Anwendungen zentral mit Login und Zwei-Faktor-Authentifizierung absichern willst. Gerade zusammen mit einem Reverse Proxy bringt dir das eine deutlich sauberere Zugangskontrolle als einzelne, verstreute App-Logins.

Wichtig ist dabei vor allem eine saubere Domainstruktur, korrekte Session-Einstellungen und eine Proxy-Integration, die wirklich zu deinem Setup passt. Wenn diese Grundlage stimmt, ist Authelia ein sehr starkes Schutzschild für Admin-Oberflächen und interne Webdienste.

Tipp:
Starte zuerst mit einer einzigen geschützten Anwendung wie https://app.example.com und rolle das Setup danach schrittweise auf weitere Dienste aus. So bleibt die Fehlersuche viel entspannter.