SSO für den selbstgehosteten Stack: Authentik und Keycloak im Vergleich

Wer einen selbstgehosteten Stack ernsthaft betreibt, hat irgendwann zehn Logins. Jedes Tool bringt einen eigenen Benutzerstamm, jedes vergisst ein Passwort, jedes hat eine andere MFA-Implementierung. Die Lösung heißt Identity Provider — und sie sollte vor den Tools kommen, nicht hinterher.

Was ein SSO bringt

Ein Login, alle Dienste: Eine Anmeldung öffnet Nextcloud, Gitea, Zammad, den Mail-Webclient und den Chat.
Eine Stelle für MFA: Zwei-Faktor wird zentral erzwungen, nicht pro Tool konfiguriert. WebAuthn/Passkeys inklusive.
Eine Stelle für Offboarding: Ein Benutzer, der geht, wird einmal gesperrt — überall.
LDAP/AD-Anbindung: Bestehende Verzeichnisse bleiben die Quelle der Wahrheit; der IdP spricht mit ihnen.

Die zwei ernsthaften Open-Source-Optionen

Keycloak ist der Platzhirsch. Java, reif, von Red Hat unterstützt, spricht jedes relevante Protokoll (OIDC, SAML, LDAP). Mächtig, aber schwerfällig — und konfigurativ anspruchsvoll.
Authentik ist der jüngere Herausforderer. Python, schlanker, mit einem modernen UI und flexibleren Flows (visualisierte Anmeldeketten). Weniger Legacy, dafür kleinere Community.

Beide unterstützen OIDC, SAML und LDAP-Anbindung. Für einen grünen Stack tendieren wir zu Authentik; für Integrationen in eine bestehende Unternehmens-IT mit SAML- requirements oft zu Keycloak.

Wie die Anbindung funktioniert

Jedes Tool wird als Relying Party (Client) im IdP registriert — mit Redirect-URL und Client-Secret.
Beim Login leitet das Tool zum IdP weiter, der Benutzer authentifiziert sich dort (inkl. MFA), und ein signiertes Token kommt zurück.
Der IdP kann Claims (Gruppen, Rollen) mitgeben, sodass das Tool weiß, welche Rechte der Benutzer hat — ohne eigene Benutzerpflege.

Was oft vergessen wird

Sicherheitsrichtlinie: Der IdP wird zum Single Point of Authentication. MFA ist nicht optional — wer ihn ohne zweite Factor betreibt, bündelt das Risiko statt zu streuen.
Backup & HA: Ein IdP-Ausfall legt den gesamten Stack lahm. Replizierte Datenbank und regelmäßige Backups sind Pflicht, kein Nice-to-have.
Session-Management: Token-Gültigkeit und Refresh-Verhalten bewusst setzen — zu lange Sessions sind ein Schwachpunkt.

Unsere Sicht

SSO ist kein Komfort-Feature, sondern Sicherheitsarchitektur. Wer MFA ernst nimmt, kann sie nicht pro Tool durchsetzen — nur zentral. Und wer Offboarding sauber lösen will, braucht eine Stelle, an der ein Benutzer existiert. Authentik und Keycloak liefern das on-prem, ohne eine Drittanbieter-Abhängigkeit.

FAQ

Warum Authentik statt Keycloak — oder umgekehrt?+

Für einen grünen Stack tendieren wir zu Authentik: Python, schlank, modernes UI, flexiblere Flows. Keycloak ist der Platzhirsch — Java, reif, von Red Hat unterstützt, spricht jedes relevante Protokoll. Wer in eine bestehende Unternehmens-IT mit SAML-Anforderungen integriert, ist mit Keycloak oft besser bedient. Beide unterstützen OIDC, SAML und LDAP.

Ist ein eigener Identity Provider nicht ein Lock-in-Risiko?+

Im Gegenteil: Authentik und Keycloak sind Open Source und sprechen offene Standards (OIDC, SAML, LDAP). Ein Wechsel ist technisch möglich, weil alle Tools als Relying Party dieselben Protokolle sprechen. Das eigentliche Risiko ist eher, den IdP ohne Replikation und Backup zu betreiben — dann wird er zum Single Point of Failure für den gesamten Stack.

Wann lohnt sich SSO für ein kleineres Unternehmen?+

Ab drei bis vier selbstgehosteten Diensten mit eigenem Login lohnt sich ein zentraler IdP — nicht nur für Komfort, sondern weil MFA nur zentral sauber durchsetzbar ist und Offboarding an einer Stelle passiert. Darunter ist der Aufwand oft höher als der Nutzen. Die Entscheidung ist also eher eine Frage der Stack-Größe als der Firmengröße.