Einer für alle: SSO im Homelab mit Authentik

Die Entwicklung vom Passwort-Wildwuchs zu Single Sign-On – und was ich dabei gelernt habe.

Ich hoste zig verschiedene Dienste in meinem Homelab. Fotoverwaltung, Dateien, Dokumentenarchiv, Medienserver, Rezepte, Netzwerkkram… die Liste ist umfangreich und wird immer länger.

Bisher laufen meine Dienste alle weitgehend unabhängig voneinander.

Für mich persönlich war das Login-Handling dabei nie ein großes Problem: Mein Passwort-Manager (1Password) handhabt die Zugangsdaten, füllt sie automatisch aus, fertig. Das sind zwar zig Dienste, zig Accounts und zig Passwörter – aber das Handling klappt seamless und ich merke davon nicht viel.

Aber: Ich bin nicht der einzige Nutzer. Einige der Dienste werden auch von Johanna oder Freunden und Bekannten genutzt. Ein paar kleine Beispiele:

• Mealie – unsere Rezepteverwaltung. Damit lassen sich prima Rezepte von beliebigen Websites importieren, so dass man sie zentral speichern kann – ohne die obligatorische Lebensgeschichte über den Urlaub der Food-Bloggerin. Zum Beispiel Cremiger Kokos-Milchreis mit Mango und Limette.
• Bar Assistant – die Cocktail-Datenbank für die Hausbar. Welche Zutaten sind da, was kann ich daraus mixen, was fehlt für den nächsten Einkauf?
• Snapotter – ein kleines, aber feines Tool zur Bildberarbeitung. Häufig genutzt: KI-unterstütztes Freistellen von Bildern (Bild hochladen, Hintergrund weg, fertig). Genau die Sorte Werkzeug, die man 2-3x im Monat brauch, für die man aber keinen Cloud-Dienst mit Account-Zwang und Abo-Modell will und keine extra installierte Software.

Und da fängt jetzt das Problem an: Für jeden dieser Dienste muss pro Nutzer ein eigener Account und ein eigenes Passwort erstellt werden. Die jeweilige (Sub-)Domain kommt noch dazu und damit für jeden Dienst ein eigenes „Wie war das nochmal?“-Paket…

Ich will aber niemandem zumuten, sich für Rezeptdatenbank, Cocktailkarte und Bildbearbeitung jeweils eigene Zugangsdaten zu merken. Und außerdem: Wenn ich einen neuen Dienst aufsetze, möchte ich ihn für Johanna oder andere mit einem Klick freischalten können – ohne neuen Account, ohne neues Passwort, ohne „ich schick dir dann die Zugangsdaten per WhatsApp“.

Die Lösung dafür gibt es seit Jahrzehnten und wird von fast jedem täglich genutzt, ohne groß drüber nachzudenken: Single Sign-On (SSO). Einmal zentral anmelden, alle freigeschalteten Dienste nutzen. Genau das, was „Login with Google/Apple/Facebook“ macht – nur eben selbst gehostet, auf meinen eigenen Diensten und ohne dass ein Cloud-Gigant mitliest.

Authentik als Türsteher

Nach etwas Recherche ist es bei mir Authentik geworden – ein selbst gehosteter Identity Provider, der bei mir seitdem unter einer eigenen Subdomain läuft und den Türsteher für (fast) alle Dienste spielt.

Warum Authentik?

• Protokoll-Vielfalt: OIDC/OAuth2, SAML, LDAP, RADIUS, SCIM – was auch immer ein Dienst spricht, Authentik unterstützt es vermutlich auch. Das ist gerade im Homelab Gold wert, da die unterschiedlichsten Dienste leider auch alle unterschiedlich angebunden werden wollen.
• Forward Auth: Das ist tatsächlich ein Gamechanger. Viele (vor allem kleinere) Self-Hosted-Tools haben keine eigene Benutzerverwaltung oder nur eine sehr rudimentäre. Authentik kann sich in Kombination mit einem Reverse Proxy einfach vor den Dienst schalten: Wer nicht eingeloggt ist, kommt gar nicht erst dran. Damit lassen sich auch Dienste absichern, die von SSO keinen Plan haben – wie das oben erwähnte Snapotter zum Beispiel. Wie das im Detail funktioniert, knüpf ich mir demnächst in einem eigenen Blogpost vor.
• Per-App-Zugriffskontrolle über Gruppen: Jeder Dienst ist in Authentik eine „Application“, und an jeder Application hängt eine Richtlinie, wer sie sehen darf. Bei mir gibt es dafür im Wesentlichen drei Gruppen: eine Admin-Gruppe (nur ich), eine Family-Shared-Gruppe (wir beide) und eine Friends-Shared-Gruppe (Familie, Freunde & Bekannte). Einen Dienst für Johanna freischalten heißt damit dann nur noch: mit einem Klick die Gruppe am Dienst-Binding ändern. Kein neuer Account, kein neues Passwort.
• Riesige Integrations-Bibliothek: Für gefühlt jeden bekannteren Self-Hosted-Dienst gibt es eine offizielle Anleitung. Die stimmt nicht immer zu 100 Prozent (dazu unten mehr), ist aber ein sehr guter Startpunkt.

Auf der Nutzerseite bekommt jeder Nutzer eine eigene App-Übersicht: Nach dem Login sieht man genau die Dienste, die für einen freigeschaltet sind – als klickbare Kacheln.

Die Schattenseiten

Neben vielen positiven Punkten gibts aber auch Nachteile:

• Leistungshunger. Server, Worker, PostgreSQL, Redis – der Stack verlangt schon ein bisschen RAM. Zum Absichern von drei bis vier Diensten fährt man mit etwas Schlankerem vermutlich besser.
• Die Lernkurve ist steil. Was genau sind bei Authentik Flows, Stages, Policies, Providers, Applications, Outposts? Da muss man sich bei den Einrichtungen der ersten ein, zwei Dienste erst mal durchbeißen. Danach wird es aber Routine.
• Single Point of Failure. Wenn der Identity Provider hängt, hängt potenziell alles. Dazu unten mehr – Stichwort „Break Glass Accounts“.

Kurz zu den Alternativen, die ich mir angeschaut (und verworfen) habe:

• Keycloak ist das, was ich überall im Enterprise-Umfeld gesehen habe. Kann alles, fühlt sich aber auch so an – für ein Homelab nach meiner Meinung Overkill mit schlechterer Doku-Lage für typische Self-Hosted-Dienste.
• Mit Authelia hatte ich geliebäugelt – das ist deutlich schlanker, wird aber ausschließlich über Konfigurationsdateien verwaltet und kommt ohne Admin-UI und App-Library. Das ist zwar super, wenn man „configuration as code“ will, aber ich will zusätzlich dann doch das grafische „ein Klick freischalten“ für mich haben.
• Pocket ID ist ein netter, minimalistischer Passkey-only-IdP. Hat aber für mich den Nachteil, dass es eben nur OIDC kann – kein SAML, kein LDAP, kein Forward Auth. Falls man nur OIDC-fähige Dienste hat, ist es aber sicherlich super.

Learnings aus der Praxis

Inzwischen hängen bei mir gut drei Dutzend Dienste hinter Authentik – von Fotoverwaltung (Immich) über Proxmox bis zu meinen NAS-Logins (Synology).

Ein paar Dinge, die ich dabei gelernt habe (und die mich jeweils zwischen zehn Minuten und einem Abend Lebenszeit gekostet haben):

1. Überprüfe die Redirect-URI. Zeichengenau, ohne Slash am Ende (oder mit – je nachdem, was der Dienst halt gerade sendet), Matching auf „Strict“. Neun von zehn Fehlern beim Einrichten waren bei mir nicht exakt passende Redirect-URIs. Tipp: im Browser einfach am redirect_uri=-Parameter in der Adresszeile ablesen, was der Dienst tatsächlich sendet, statt sich nur auf die Doku zu verlassen.
2. Am Provider nur einen Signing Key setzen, keinen Encryption Key. Die meisten Dienste können mit verschlüsselten Tokens nichts anfangen und quittieren das mit so super Fehlermeldungen wie z.B. „found 5 parts“. Das war mein zweihäufigster Stolperstein.
3. Erst E-Mail-Adressen angleichen, dann SSO aktivieren. Die meisten Dienste matchen den SSO-Login über die E-Mail-Adresse mit bestehenden Konten. Blöd für mich, da ich in der Regel meine Zugänge in der Vergangenheit im Format dienst@meine-domain aufgesetzt habe. Wer das vorher nicht angleicht, hat hinterher zwei Accounts – den alten mit allen Daten und einen frischen, leeren SSO-Account. Manche Dienste matchen auch über den Usernamen. Ein Blick in die Doku vorher ist da hilfreich…

4. Immer einen Break-Glass-Zugang behalten. Bei jedem Dienst bleibt bei mir der lokale Admin-Login bestehen. Wenn Authentik (oder DNS, oder der Reverse Proxy…) mal klemmt, will ich nicht komplett ausgesperrt sein – besonders nicht beim DNS-Server oder dem Monitoring.
5. Nicht jeder Dienst kann (oder darf). Stirling-PDF hat natives OIDC hinter eine Bezahllizenz gepackt 👎, bei Uptime Kuma hängt der OIDC-Support seit Monaten in einem ge-vibecodeten Pull Request, und Umami lehnt SSO upstream schlicht ab. Für solche Fälle: Forward Auth davor oder bewusst abgekapselt weiterlaufen lassen.
6. Forward Auth und API-Clients vertragen sich nicht. Mobile Apps, die per API-Key auf einen Dienst zugreifen, scheitern am Login-Redirect. Die laufen bei mir stattdessen per VPN direkt auf den Dienst. Klappt grundsätzlich – aber gut zu wissen, bevor man sich wundert.

Fazit

War das jetzt unbedingt nötig? Für mich allein: vermutlich nicht, 1Password hätte auch weiterhin gereicht.

Aber sobald mehr als eine Person das Homelab nutzt, sieht das schon deutlich anders aus. „Melde dich einfach mit deinem Account an, du siehst dann alles, was für dich freigeschaltet ist“ ist ein fundamental besseres Onboarding als „ich leg dir mal auf fünf Diensten je einen Account an und schicke dir die Passwörter“.

Der Rollout ist noch nicht 100% abgeschlossen – ein paar Dienste warten noch auf ihren Forward-Auth-Anschluss, und das Onboarding für alle Nutzer steht auch noch aus. Aber die grundlegende Basis steht.

Der Moment, in dem man einen frisch aufgesetzten Dienst mit einem einzigen Gruppen-Binding für alle Nutzer freischaltet – ohne einen einzigen neuen Account anzulegen – der ist schon ziemlich befriedigend.

---

Diesen Beitrag gibt es auch auf Englisch.
Die englische Fassung findest du hier: One for All: SSO in the Homelab with Authentik.