SSO für interne Dienste mit Authentik in der Praxis

Authentik ist nicht nur eine Login-Oberfläche, sondern kann in Self-Hosted-Umgebungen schnell zum zentralen Einstiegspunkt für interne Dienste werden. Genau dort spielt Single Sign-On seinen grössten Vorteil aus: weniger Passwort-Chaos, klarere Zugriffskontrolle und ein deutlich professionellerer Zugang zu internen Anwendungen.

In dieser Anleitung schauen wir uns SSO mit Authentik in der Praxis an. Dabei geht es weniger um die Grundinstallation und mehr darum, wie du interne Dienste sauber anbindest, wann du Proxy Provider, OAuth2 oder andere Wege nutzt und welche Stolpersteine bei Reverse Proxy, Outposts und Headern häufig auftreten.

1. Was SSO im Alltag wirklich bringt

Single Sign-On bedeutet vereinfacht: Benutzer melden sich einmal an und greifen danach auf mehrere Dienste mit zentral verwalteter Identität zu. Für interne Tools ist das besonders wertvoll.

Typische Vorteile:

• ein zentrales Benutzer- und Gruppenmodell
• weniger lokale Accounts in jeder einzelnen Anwendung
• einfachere MFA-Durchsetzung
• klarere Deaktivierung von Zugängen bei Austritt oder Rollenwechsel
• saubererer Gesamtauftritt für interne Admin- oder Support-Portale

Gerade bei mehreren Self-Hosted-Diensten ist das oft ein spürbarer Qualitätssprung.

2. Die wichtigste Praxisfrage: Unterstützt der Dienst selbst SSO?

Bevor du irgendetwas in Authentik anlegst, stelle dir immer zuerst diese Frage:

Kann die Anwendung selbst OAuth2, OpenID Connect, SAML oder LDAP?

Wenn ja, ist das oft der sauberste Weg. Wenn nein, kommt häufig der Authentik Proxy Provider ins Spiel. Die offizielle Authentik-Dokumentation beschreibt Providers als die eigentliche Authentisierungsmethode für eine Anwendung.

Praxisregel:

• wenn die App OIDC oder SAML kann: möglichst direkt integrieren
• wenn sie nichts davon kann: Proxy Provider prüfen
• wenn es nur um Netz- oder Header-Schutz vor einer bestehenden Web-App geht: Outpost- und Proxy-Modell sauber planen

3. Die Hauptbausteine in Authentik verstehen

Für praktische SSO-Setups begegnen dir meist diese Objekte:

• Application: die sichtbare App in Authentik
• Provider: definiert die Art der Anbindung, zum Beispiel Proxy oder OAuth2
• Outpost: der technische Dienst, der bestimmte Provider-Typen ausliefert oder proxyt
• Policies: Regeln für Zugriff, Gruppen oder Bedingungen

Die offizielle Dokumentation beschreibt Outposts als eigenständige Komponenten, die sich mit dem Authentik-Core verbinden und ihre Konfiguration darüber beziehen. Genau deshalb sind Reverse-Proxy- und WebSocket-Themen hier wichtig.

4. Wann ein Proxy Provider sinnvoll ist

Der Proxy Provider ist besonders nützlich für Webanwendungen, die selbst kein sauberes modernes SSO unterstützen. Dann setzt du einen Authentik-Outpost vor die Anwendung und schützt sie darüber.

Typische Beispiele:

• interne Dashboards
• Admin-Panels
• ältere Web-Tools
• eigene kleine interne Anwendungen ohne eigene OIDC-Integration

Authntik weist in der Dokumentation und im Troubleshooting ausdrücklich darauf hin, dass Pfade unter /outpost.goauthentik.io öffentlich erreichbar sein müssen, weil sie für Authentisierung und Flow-Steuerung gebraucht werden. Genau das wird in der Praxis oft vergessen.

5. Reverse Proxy sauber mitdenken

Wenn Authentik oder ein Proxy-Outpost hinter einem Reverse Proxy laufen, müssen bestimmte Header korrekt weitergegeben werden. Die offizielle Dokumentation nennt insbesondere:

• Host
• X-Forwarded-Proto
• X-Forwarded-For
• bei WebSockets zusätzlich Connection: Upgrade und Upgrade: WebSocket

Wenn diese Header fehlen oder falsch gesetzt sind, entstehen oft sehr verwirrende Fehlerbilder: Schleifen beim Login, falsche Weiterleitungen, kaputte IP-Erkennung oder nicht funktionierende Outposts.

Ausserdem weist Authentik darauf hin, dass bei nicht privaten Proxy-Quellen die trusted proxy CIDRs korrekt gesetzt werden müssen, damit Client-IP-Adressen sauber erkannt werden.

6. Ein typischer Praxisaufbau

Ein häufiges Muster in Self-Hosted-Umgebungen sieht so aus:

• auth.example.com für den Authentik-Core
• grafana.example.com oder tools.example.com für eine geschützte Zielanwendung
• Reverse Proxy wie Caddy, Nginx oder Traefik davor
• Proxy Outpost für Anwendungen ohne eigene SSO-Fähigkeit

Wichtig ist, dass Domainstruktur, Weiterleitungen und Header von Anfang an klar geplant sind. Gerade bei mehreren internen Tools lohnt sich eine kleine Namenskonvention sehr.

7. Zugriff nicht nur technisch, sondern auch organisatorisch planen

Ein gutes SSO-Setup ist mehr als funktionierende Authentisierung. Du solltest dir auch überlegen:

• welche Gruppen welchen Dienst sehen dürfen
• wo MFA Pflicht ist
• welche Apps nur intern erreichbar sein sollen
• wie Admin- und Normalbenutzer getrennt werden

Gerade Authentik ist stark, wenn du diese Regeln sauber in Gruppen, Policies und Rollen übersetzt statt einfach alle Benutzer überall durchzulassen.

8. Welche Anwendungen sich besonders gut eignen

In der Praxis sind oft diese internen Dienste sehr gute Kandidaten:

• Grafana
• Portainer
• interne Admin-Dashboards
• selbst entwickelte interne Tools
• Dienste, die bisher nur mit Basic Auth oder lokalen Konten geschützt waren

Bei Anwendungen mit eigener OIDC- oder SAML-Unterstützung würde ich diese native Integration meist bevorzugen. Das ist langfristig oft sauberer als vorgeschaltete Proxy-Logik.

9. Typische Fehler in der Praxis

• Outpost-Pfade unter /outpost.goauthentik.io werden nicht erreichbar gemacht
• Reverse Proxy leitet Host oder X-Forwarded-Proto nicht korrekt weiter
• WebSocket-Upgrades fehlen
• trusted proxies sind falsch oder gar nicht definiert
• man nutzt Proxy Provider, obwohl die Zielanwendung eigentlich direkt OIDC könnte
• Gruppen und Policies werden zu spät geplant und nachher chaotisch nachgerüstet

Genau diese Punkte verursachen viele der frustrierenden Fehler, die dann fälschlich Authentik selbst angelastet werden.

10. Was ich in der Praxis empfehlen würde

• pro Dienst zuerst prüfen, ob native OIDC- oder SAML-Anbindung möglich ist
• Proxy Provider nur dort einsetzen, wo er wirklich gebraucht wird
• eine klare Domain- und Gruppenstrategie festlegen
• MFA für Admin-relevante Dienste konsequent einsetzen
• Reverse-Proxy-Header und Outpost-Pfade systematisch prüfen

Damit wird Authentik nicht nur ein Login-System, sondern eine saubere zentrale Zugriffsschicht.

11. Fazit

SSO mit Authentik ist in der Praxis vor allem dann stark, wenn du nicht einfach nur Logins zentralisierst, sondern Anwendungen bewusst passend anbindest: native SSO dort, wo es möglich ist, Proxy Provider dort, wo es wirklich nötig ist, und dazu eine saubere Reverse-Proxy- und Policy-Struktur.

Wenn diese Basis stimmt, gewinnst du deutlich mehr Übersicht, konsistentere Sicherheit und einen spürbar professionelleren Zugriff auf interne Dienste.

Tipp:
Starte nicht gleich mit zehn Anwendungen. Binde zuerst einen einzigen internen Dienst sauber an, dokumentiere die Schritte und baue dein Authentik-Modell danach Stück für Stück weiter aus.