Authelia: leichter SSO- und 2FA-Authorization-Proxy für nginx und Traefik

Was ist Authelia?

Authelia ist ein quelloffener Authentication-Server und Authorization-Proxy unter Apache-2.0-Lizenz, der Mai 2026 als die schlankste praktische SSO-Lösung für CH-KMU gilt. Das Projekt wurde 2018 als Python-Anwendung gestartet, 2020 komplett in Go neugeschrieben und beträgt seitdem weniger als 30 MB Binary-Grösse. Es läuft als Single-Binary oder Docker-Container, braucht 50-100 MB RAM in produktivem Einsatz, und integriert sich mit nginx, Traefik, HAProxy, Caddy und Envoy als Reverse-Proxy-Sidecar.

Das Funktionsprinzip ist klar: Authelia steht zwischen dem öffentlich erreichbaren Reverse-Proxy und den internen Diensten. Wenn ein Nutzer eine geschützte URL aufruft (zum Beispiel n8n.treuhand-müller.ch), leitet der Reverse-Proxy die Anfrage zunächst an Authelia. Authelia prüft, ob der Nutzer eingeloggt ist (Cookie-Token), ob die Session noch gültig ist, und ob die konfigurierte Authorization-Stufe für diese URL erfüllt ist (1-Faktor, 2-Faktor, bestimmte Gruppen-Zugehörigkeit). Bei erfüllten Bedingungen erlaubt Authelia den Durchstich zum Backend; sonst leitet es auf die Login-Seite weiter.

Die Konfiguration läuft über eine einzige YAML-Datei (configuration.yml) plus eine Zugriffs-Regel-Datei. Authentication-Backends: lokale File-basierte Nutzerliste für Mini-Setups, LDAP/Active Directory für Mittelstand-Setups, Authentik-/Keycloak-Integration als OIDC-Provider für hybride Setups. Storage-Backends für Sessions und 2FA-Faktoren: SQLite (Default), PostgreSQL, MySQL. Cache-Backend: Redis für Multi-Instance-Setups.

Zwei-Faktor-Authentisierung unterstützt Mai 2026 vier Methoden: (1) TOTP via Authenticator-App (Google Authenticator, Authy, 1Password, Bitwarden), (2) WebAuthn/FIDO2 mit Hardware-Keys (YubiKey, SoloKeys, Titan-Key), (3) Mobile Push via Duo-Integration, (4) E-Mail-OTP als Fallback. FIDO2-Hardware-Keys sind die phishing-resistenteste Methode und sollten 2026 Standard für Admin-Accounts sein.

Authorization-Regeln sind YAML-Listen, die pro URL-Muster die nötige Stufe definieren. Beispiel: hauptdomain treuhand-müller.ch braucht nur eine valide Session (1-Faktor), Admin-Backend admin.treuhand-müller.ch verlangt 2-Faktor, Vault-UI vault.treuhand-müller.ch verlangt 2-Faktor plus Gruppen-Zugehörigkeit "admins". Die Regeln werden in Reihenfolge ausgewertet, erstes Match gewinnt.

Warum es für CH-KMU und Treuhand zählt

Authelia löst für CH-KMU drei konkrete Probleme.

SSO statt verteilte Logins: Ein typisches Treuhand-Büro betreibt 5-10 interne Dienste (Nextcloud, n8n, Grafana, Vault-UI, Wazuh-Dashboard, Mandantenportal). Ohne SSO hat jeder Mitarbeiter 5-10 separate Logins, eigene Passwörter, eigene Vergessen-Workflows. Authelia stellt eine zentrale Login-Seite voraus, der Mitarbeiter loggt sich einmal ein, alle Dienste sehen ihn als authentifiziert. Mitarbeiter-Onboarding und Offboarding wird zu einer Stelle reduziert.

Phishing-resistente 2FA via FIDO2: Klassisches TOTP-2FA (Authenticator-App) ist gegen Phishing-Angriffe nur teilweise robust -- ein gefaelschtes Login-Formular kann TOTP-Codes in Echtzeit weiterleiten. FIDO2-Hardware-Keys (YubiKey, SoloKeys) sind strukturell phishing-resistent: der Key prüft die Domain kryptografisch und gibt den Token nur an die echte URL frei. Bei Anwaltskanzleien mit Berufsgeheimnis nach StGB Art. 321 ist FIDO2 Mai 2026 Standard für alle Admin-Accounts und sollte für alle Mitarbeiter-Accounts gelten.

Authorization-Proxy statt App-Auth: Viele interne Tools (Grafana, n8n, Loki, Qdrant-UI) haben eigene Login-Mechanismen mit unterschiedlichen Sicherheits-Niveaus. Manche unterstützen kein 2FA out-of-the-box. Authelia löst das Problem strukturell: die Tools müssen nicht selbst Auth implementieren, Authelia übernimmt das im Proxy-Layer. Das vereinheitlicht das Sicherheits-Niveau und reduziert Maintenance.

Regulatorischer Bezug: Art. 8 revFADP verlangt Schutzmassnahmen nach dem Stand der Technik. 2FA für administrative Accounts ist 2026 Stand der Technik und wird vom EDÖB-Leitfaden, von ISO 27001 (Annex A.9.4.2) und von allen Schweizer Cyber-Versicherungen verlangt. Authelia liefert das mit minimalem Setup-Aufwand.

KMU-Fit besonders: Authelia braucht keine eigene Datenbank-Infrastruktur (SQLite reicht für Setups bis 100 Nutzer), keine Postgres-Cluster, kein eigenes Identity-Schema. Setup-Aufwand 2-4 Stunden für ein produktives Treuhand-Setup mit 10-20 Nutzern. Im Vergleich zu Authentik (Python-basiert, mit Postgres-Pflicht) ist Authelia die deutlich schlanke Wahl für kleine Setups.

Setup mit nginx und Docker-Compose

Wir zeigen ein produktives Authelia-Setup mit nginx-Reverse-Proxy, das wir bei Fairlane für Mandanten-Deployments einsetzen.

```yaml version: "3.8" services: authelia: image: authelia/authelia:4.39 container_name: authelia restart: unless-stopped volumes: - ./authelia-config:/config environment: - TZ=Europe/Zurich ports: - "127.0.0.1:9091:9091" redis: image: redis:7-alpine container_name: authelia-redis restart: unless-stopped volumes: - ./redis-data:/data ```

Konfigurationsdatei authelia-config/configuration.yml (verkürzt):

```yaml server: address: tcp://0.0.0.0:9091 log: level: info totp: issuer: treuhand-müller.ch authentication_backend: file: path: /config/users_database.yml access_control: default_policy: deny rules: - domain: portal.treuhand-müller.ch policy: one_factor - domain: ["n8n.treuhand-müller.ch", "grafana.treuhand-müller.ch"] policy: two_factor - domain: ["vault.treuhand-müller.ch", "admin.treuhand-müller.ch"] policy: two_factor subject: "group:admins" session: name: authelia_session domain: treuhand-müller.ch expiration: 1h inactivity: 5m redis: host: authelia-redis port: 6379 storage: encryption_key: <random-64-char-key> local: path: /config/db.sqlite3 notifier: smtp: host: smtp-relay.brevo.com port: 587 username: <brevo-user> password: <brevo-key> sender: "Authelia <auth@treuhand-müller.ch>" identity_providers: oidc: hmac_secret: <random> issuer_private_key: | <pem-key> ```

nginx-Snippet für geschützte Subdomain: ```nginx location / { set $upstream_authelia http://authelia:9091/api/verify; auth_request /authelia; auth_request_set $target_url $scheme://$http_host$request_uri; auth_request_set $user $upstream_http_remote_user; proxy_set_header Remote-User $user; error_page 401 =302 https://auth.treuhand-mueller.ch/?rd=$target_url; proxy_pass http://n8n:5678; } location /authelia { internal; proxy_pass $upstream_authelia; proxy_set_header Host $host; proxy_set_header X-Original-URL $scheme://$http_host$request_uri; proxy_set_header X-Forwarded-Method $request_method; proxy_pass_request_body off; proxy_set_header Content-Length ""; } ```

Nutzer-Datei users_database.yml mit Argon2id-Hashes: ```yaml users: vitalij: displayname: "Vitalij Strigailo" password: "$argon2id$v=19$m=65536,t=3,p=4$<hash>" email: vitalij@treuhand-müller.ch groups: ["admins", "developers"] ```

Passwort-Hash erzeugen mit: authelia hash-password "MeinPasswort". Empfohlene Parameter Argon2id mit memory 65536, iterations 3, parallelism 4.

FIDO2-Hardware-Key registrieren: Nutzer loggt sich erstmals via TOTP ein, geht zu auth.treuhand-müller.ch/2fa, wählt "Add Webauthn Device", druckt Knopf am YubiKey. Authelia speichert den Public Key in der SQLite-DB. Bei nächstem Login wird der Key abgefragt -- USB-Stecken plus Knopfdruck reicht.

Authelia-Setup in 5 Schritten

1. 01Reverse-Proxy aufsetzen (nginx, Traefik oder Caddy) mit TLS via Lets Encrypt; auth.treuhand-müller.ch-Subdomain bereitstellen.
2. 02Authelia via Docker-Compose deployen mit Redis für Session-Cache; configuration.yml mit Access-Control-Regeln (default deny, explizite Erlaubnis pro Domain).
3. 03Nutzer anlegen: authelia hash-password für jeden Nutzer, users_database.yml mit Argon2id-Hashes und Gruppen-Zuordnung; SMTP-Notifier via Brevo testen.
4. 04Reverse-Proxy-Snippets pro geschützter Subdomain einfügen: auth_request /authelia (nginx) oder ForwardAuth (Traefik); error_page 401 auf Login-Subdomain leiten.
5. 052FA für alle Nutzer erzwingen: TOTP für alle, FIDO2-Hardware-Keys (YubiKey 5C) für Admin-Accounts; Recovery-Codes ausdrucken und sicher lagern.

Wann Authelia einsetzen

Authelia ist Mai 2026 in vier Konstellationen die richtige Wahl.

Kleine bis mittlere CH-KMU (3-50 Nutzer) ohne LDAP: Solo-Treuhand, Anwaltskanzlei, kleine Agentur. File-basiertes Nutzer-Backend reicht völlig, kein Active Directory nötig. Setup-Aufwand 2-4 Stunden, Wartung 1-2 Stunden pro Monat. Im Vergleich zu Authentik (Postgres-Pflicht, Python-Stack) ist Authelia deutlich pragmatischer.

Reverse-Proxy-fokussierte Stacks (nginx, Traefik, Caddy): Authelia integriert sich nativ via auth_request bei nginx, ForwardAuth bei Traefik, forward_auth bei Caddy. Der gesamte Auth-Layer läuft im Proxy, die Apps müssen nichts wissen. Das macht Authelia zur Wahl, wenn Sie einen einheitlichen Proxy-Stack haben und nur einen Auth-Layer brauchen.

Phishing-resistente FIDO2-2FA für Admin-Accounts: Authelia unterstützt WebAuthn/FIDO2 mit YubiKey und Co. nativ. YubiKey 5C kostet ca. CHF 80 pro Stück. Für eine Anwaltskanzlei mit 5 Admin-Accounts sind das CHF 400 einmalig für phishing-resistente 2FA. Im Vergleich zu reinem TOTP ist das eine deutliche Sicherheits-Steigerung.

Minimaler Footprint und einfaches Audit: Single-Binary, eine YAML-Konfiguration, SQLite-DB. Auditoren können die Konfiguration in einer Stunde komplett prüfen. Im Vergleich zu Authentik mit über 20 Datenbank-Tabellen und Python-Stack ist Authelia deutlich transparenter.

Authelia ist auch in hybriden Setups gut: als Authorization-Proxy vor allen internen Diensten, mit Authentik oder Keycloak als zentraler OIDC-IdP. Authelia delegiert dann das Login an den IdP, kuemmert sich aber selbst um die URL-basierte Authorization. Das skaliert von KMU bis Mittelstand.

Wann Authentik oder Keycloak besser sind

Drei Fälle, in denen Authelia Mai 2026 nicht die richtige Wahl ist.

SAML-Pflicht oder OIDC-Provider-Rolle als Hauptanwendung: Authelia ist primär Authorization-Proxy, mit OIDC-Provider-Funktionalität als Zusatz. Wer SAML-2.0-Provider-Rolle braucht (klassische Enterprise-Apps wie SAP, Oracle, Workday) oder ein vollwertiges Identity-Management-System mit User-Self-Service, Gruppen-Verwaltung via UI, externe Identity-Provider-Federation, ist mit Authentik oder Keycloak besser bedient.

LDAP-Hauptanwendung als IdP: Authelia kann gegen LDAP authentifizieren, aber nicht selbst als LDAP-Server agieren. Wer einen LDAP-Server für Mail (Postfix-SMTP-Auth), File-Server (Samba), VPN-Auth-Backend braucht, kommt um Authentik (mit eigenem LDAP-Outpost) oder Keycloak nicht herum.

Hochkomplexe Berechtigungs-Modelle: Authelias Access-Control ist URL-basiert mit Gruppen-Matching. Komplexere Modelle (Attribut-basierte Authorization, dynamische Rollen basierend auf Mandanten-Zugehörigkeit, Multi-Tenant-Setups mit unterschiedlichen Berechtigungs-Schemas) sind in Authelia mühsam abzubilden. Hier ist Keycloak oder Authentik mit Policy-Engine besser.

Generelle Fallen bei Authelia-Setups: (a) Default-Policy auf "allow" lassen statt "deny" -- jeder ungesicherte Pfad wird unbeabsichtigt durchgereicht. (b) Argon2id-Parameter zu schwach setzen -- memory unter 65536 macht Passwörter angreifbar. (c) Session-Timeout zu lang setzen -- 1h ist Standard für interne Tools, für Admin-Backend kürzer (15 Minuten). (d) Encryption-Key in der YAML hardcoden statt aus Vault holen -- Secret-Leak über Backups. (e) SMTP-Notifier nicht testen -- 2FA-Recovery-Mails kommen nicht an, Nutzer sind ausgesperrt.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Authelia -- official documentation · 2026-05
2. Authelia GitHub -- v4.39 release notes · 2026-04
3. FIDO Alliance -- WebAuthn and FIDO2 specs · 2026-03
4. EDÖB -- Technische und organisatorische Massnahmen · 2026-04
5. OWASP Authentication Cheat Sheet · 2026-02