Was ist Keycloak? Die Kurzantwort
Kaum eine Infrastruktur-Entscheidung hat 2026 mehr versteckte Tragweite als die Identitätsfrage: Wer verwaltet Logins, Rollen und Sessions deiner Kunden und Mitarbeiter – und zu welchem Preis? SaaS-Identity-Dienste rechnen pro aktivem Nutzer ab, was bei wachsenden Portalen zur teuersten Zeile der Cloud-Rechnung werden kann. Und sie verwalten dabei das sensibelste Datenasset überhaupt: Identitäten. Keycloak ist die Open-Source-Antwort auf beides.
Zum Begriff selbst: Identity- und Access-Management bündelt zwei Aufgaben, die im Alltag gern verwechselt werden. Authentifizierung klärt, wer jemand ist – per Login, MFA oder Passkey. Autorisierung klärt, was diese Person darf: Rollen, Rechte, Gruppen. Keycloak übernimmt beides zentral, deine Anwendungen fragen nur noch nach, statt eigene Login-Logik zu pflegen.
Dieser Überblick beantwortet die Fragen, die in Entscheider-Runden tatsächlich fallen: Welche Produkte ersetzt Keycloak? Wie aktuell und zukunftssicher ist das Projekt? Welche vier Konzepte musst du kennen, um ein Angebot bewerten zu können? Und wann ist Keycloak schlicht die falsche Wahl? Alle recherchierten Zahlen sind auf dem Stand vom September 2026 und am Ende des Artikels belegt.
Welche Produkte ersetzt Keycloak?
Keycloak übernimmt die Identitätsschicht: Login und SSO über alle Anwendungen, Nutzer- und Rollenverwaltung, MFA, Self-Service (Passwort-Reset, Profil) und die Föderation bestehender Verzeichnisse. Damit substituiert es je nach Ausgangslage sehr unterschiedliche Systeme:
| System | Modell | Wann Keycloak die Alternative ist |
|---|---|---|
| Auth0 (Okta) | SaaS-IdP, Tarife skalieren mit aktiven Nutzern (MAU) | wenn Nutzerzahlen die Kosten treiben oder Datenhoheit gefordert ist |
| Okta Workforce | SaaS, Preis pro Nutzer/Monat | wenn Mitarbeiter-SSO ohne Dauerabo pro Kopf gewünscht ist |
| Microsoft Entra ID (B2C/External ID) | Cloud-IdP im Microsoft-Ökosystem | wenn Kundenportale unabhängig von Microsoft-Bindung und -Preislogik laufen sollen |
| AWS Cognito | Cloud-IdP, nutzungsbasiert | wenn Sie AWS-Lock-in vermeiden oder komplexe Flows brauchen, an denen Cognito-Anpassbarkeit endet |
| Firebase Auth | Google-Cloud-Dienst | wenn aus dem App-Prototyp ein B2B-Produkt mit Rollen, SSO und Compliance-Anforderungen wird |
| Auth-Eigenbau | selbst entwickelte Login-/Session-Logik | Keycloak ersetzt den riskantesten Eigenbau überhaupt – Security-Logik gehört nicht selbst geschrieben |
Zur Abgrenzung: Keycloak ersetzt kein CRM und kein Nutzer-Datenmodell deiner Anwendung – es ist die Authentifizierungs- und Autorisierungsschicht davor. In unseren Projekten arbeitet es häufig neben Supabase: Supabase Auth für schlanke Einzel-Apps, Keycloak sobald SSO über mehrere Anwendungen, Verzeichnis-Anbindung oder feingranulare Rollen gefragt sind.
Das Muster hinter der Tabelle: Keycloak ersetzt weniger einzelne Funktionen als ein Geschäftsmodell. Alle genannten Dienste monetarisieren pro Nutzer oder pro Login; Keycloak entkoppelt die Identitätsschicht von dieser Preislogik. Nach unserer Projekterfahrung rechnet sich der Wechsel deshalb selten bei 500 Nutzern – aber fast immer, sobald die Nutzerzahl fünfstellig wird und jede Preisstaffel des Anbieters zur Verhandlung über dein Wachstum gerät.
Die Vorteile eines Open-Source-IAM
Keine nutzerbasierten Lizenzkosten: Ob 1.000 oder 500.000 Nutzer – die Softwarekosten bleiben null. Bei SaaS-IdPs ist die MAU-Rechnung der größte versteckte Skalierungskostenblock.
Datenhoheit beim sensibelsten Asset: Identitäten, Credentials und Sessions liegen auf deiner EU-Infrastruktur – keine Drittland-Transfers, kurze Auftragsverarbeitungsketten, volle Audit-Kontrolle.
Volle Protokoll- und Legacy-Breite: OIDC, OAuth2 und SAML für Moderne wie Alt-Systeme, LDAP-/Active-Directory-Federation für bestehende Verzeichnisse.
Anpassbare Authentifizierungs-Flows: Registrierung, Step-up-MFA, kundenspezifische Login-Journeys und eigene Erweiterungen (SPIs) – ohne auf Feature-Roadmaps eines Anbieters zu warten.
Exit-Sicherheit und Governance: Der Dienst läuft weiter, egal was ein Anbieter mit Preisen oder Produkten macht – als CNCF-Projekt mit Red-Hat-Herkunft ist Keycloak zudem ungewöhnlich breit abgesichert.
White-Labeling inklusive: Login-Oberflächen laufen unter deiner Marke und Domain – kein „Powered by"-Fremdauftritt im sensibelsten Moment der Nutzerbeziehung.
Der Merksatz für die Vorstandsvorlage: Open-Source-IAM tauscht laufende Lizenzkosten gegen einmalige Projektkosten und kalkulierbaren Betrieb. Ob dieser Tausch sich lohnt, ist keine Glaubensfrage, sondern eine Rechenaufgabe mit deiner Nutzerzahl.
Aktuelle Version, Release-Rhythmus und CNCF-Status
Stand 28. September 2026 ist Keycloak 26.7.4 die aktuelle Version, erschienen am 16. September 2026. Wichtiger als die Nummer ist der Rhythmus dahinter: Mit Version 26.0 im Oktober 2024 hat das Projekt seinen Takt bewusst verlangsamt – weg von vier Major-Releases pro Jahr, hin zu vier Minor-Releases jährlich und einem Major-Release alle zwei bis drei Jahre.
| Release-Typ | Rhythmus | Jüngstes Beispiel |
|---|---|---|
| Major (26.0) | alle zwei bis drei Jahre | Oktober 2024 |
| Minor (26.6, 26.7) | viermal pro Jahr | 26.7.0 am 9. Juli 2026 |
| Patch (26.7.1–26.7.4) | laufend, zuletzt etwa alle zwei Wochen | 26.7.4 am 16. September 2026 |
Was der Rhythmus für dich bedeutet
Für deine Planung heißt das: Upgrades sind berechenbar geworden. Breaking Changes kommen seit 26.0 nur noch als Opt-in – ein Feature wird in einem Minor-Release als veraltet markiert, entfernt wird es erst im nächsten Major-Release. Die Zeiten, in denen jedes Quartal ein Versionssprung mit Migrationsaufwand anstand, sind vorbei. Für die Budgetplanung genügt in der Regel ein größeres Upgrade-Fenster pro Jahr.
Berechenbar heißt allerdings nicht optional: Allein zwischen dem 5. August und dem 16. September 2026 erschienen vier Patch-Releases (26.7.1 bis 26.7.4). Identity-Systeme stehen auf jeder Angreifer-Liste ganz oben, Patches sind darum Pflicht statt Kür. Wie du Updates ohne Wartungsfenster-Drama organisierst, zeigt unser Leitfaden Keycloak-Upgrade in der Praxis.
Praxis-Hinweis für Auswahlgespräche: Frag einen Dienstleister nicht, ob er Keycloak kann, sondern welche Version er gerade betreibt und wie sein Patch-Prozess aussieht. Antworten deutlich unterhalb der 26er-Linie deuten auf verschleppte Upgrades hin – und damit auf offene Sicherheitslücken. Dieselbe Frage funktioniert übrigens bei jedem Open-Source-Baustein deines Stacks.
CNCF-Status und Governance
Keycloak entstand bei Red Hat und ist seit dem 10. April 2023 Incubating-Projekt der Cloud Native Computing Foundation (CNCF), derselben Stiftung, die Kubernetes trägt. Incubating ist die mittlere von drei Reifestufen: Produktive Nutzung durch mehrere Organisationen und eine aktive Contributor-Basis sind nachgewiesen, der Graduated-Status steht noch aus.
Für deine Risikobewertung zählt die Konstruktion dahinter: Die CNCF koppelt die Zukunft des Projekts von den Interessen eines einzelnen Herstellers ab. Red Hat bleibt mit dem kommerziellen «Red Hat Build of Keycloak» an Bord, entscheidet aber nicht mehr allein – ein seltener Fall von doppelter Absicherung bei Open-Source-Infrastruktur.
Die Kernkonzepte für Entscheider
Keycloak organisiert Identitäten in Realms (getrennte Mandanten, z. B. Kunden vs. Mitarbeiter), Anwendungen docken als Clients über OIDC oder SAML an. Bestehende Nutzerbestände bindet User Federation an (LDAP, Active Directory), externe Identitäten kommen per Identity Brokering dazu (z. B. „Login mit Google" oder ein Partner-IdP).
So weit die 90-Sekunden-Fassung. Diese vier Begriffe tauchen in jedem Keycloak-Angebot und jedem Architektur-Review auf – deshalb hier, was sie für deine Entscheidung bedeuten.
Realm: der getrennte Mandant
Ein Realm ist ein vollständig isolierter Verwaltungsbereich: eigene Nutzer, eigene Rollen, eigene Login-Optik, eigene Sicherheitsregeln. Das typische Mittelstands-Muster sind zwei Realms – einer für Mitarbeiter mit AD-Anbindung, einer für Kunden mit Self-Service-Registrierung. Für dich relevant, weil eine einzige Keycloak-Instanz damit mehrere Nutzerwelten getrennt bedient: Das neue Kundenportal braucht keine zweite Identity-Infrastruktur. Auch Zukäufe profitieren: Eine übernommene Firma lässt sich als weiterer Realm andocken.
Client: die angebundene Anwendung
Jede Anwendung, die sich ihr Login von Keycloak holt, ist ein Client: das Kundenportal, das interne Dashboard, die Mobile-App, auch das ERP mit SAML-Schnittstelle. Für die Projektkalkulation ist das die wichtigste Stellgröße: Der Aufwand einer Keycloak-Einführung wächst weniger mit der Nutzerzahl als mit der Zahl der Clients und deren Altlasten. Zehn saubere OIDC-Apps sind schneller angebunden als drei Legacy-Systeme.
Identity Brokering: fremde Logins annehmen
Brokering heißt: Keycloak akzeptiert Identitäten anderer Anbieter und übersetzt sie für deine Anwendungen. Das beginnt beim «Login mit Google» und endet beim B2B-Fall, der in Kundenportalen den Ausschlag gibt: Dein Großkunde will, dass sich seine Mitarbeiter mit ihrem Firmen-Login (Entra ID, Okta) in deinem Portal anmelden. Mit Brokering ist dieses Enterprise-SSO Konfigurationsarbeit statt Entwicklungsprojekt – ohne Brokering hieße dieselbe Anforderung: Individualentwicklung pro Kunde.
User Federation: bestehende Verzeichnisse anbinden
Federation löst das umgekehrte Problem: Deine Nutzer existieren bereits, typischerweise in einem Active Directory oder LDAP-Verzeichnis. Keycloak bindet das Verzeichnis an, statt es zu ersetzen – die IT behält ihre gewohnte Nutzerpflege, die Anwendungen bekommen modernes SSO obendrauf. In Modernisierungsprojekten ist das oft das entscheidende Argument, weil niemand am ersten Tag das Active Directory anfassen will.
MFA, Passkeys/WebAuthn und Session-Management sind Kernfunktionen, Login-Themes und Server-Erweiterungen (SPIs) machen Flows und Optik anpassbar. Technisch läuft Keycloak als Container auf der Quarkus-Runtime – von der Einzelinstanz bis zum hochverfügbaren Cluster.
Gerade Passkeys sind 2026 mehr als ein Häkchen auf der Funktionsliste: Sie ersetzen Passwörter durch phishing-resistente Anmeldung. Was das für dein Kundenportal praktisch bedeutet, liest du in Keycloak und Passkeys.
Mit diesen vier Begriffen kannst du jedes Keycloak-Angebot in fünf Minuten plausibilisieren: Wie viele Realms sind geplant, wie viele Clients werden angebunden, welche Verzeichnisse föderiert, welche fremden IdPs gebrokert? Aus den vier Antworten ergibt sich der Projektumfang – nicht aus der Nutzerzahl.
SSO, OIDC und SAML: die Kürzel eingeordnet
Vorab die Begriffsklärung: Single Sign-on (SSO) ist das Ziel – einmal anmelden, alle Anwendungen nutzen. OIDC und SAML sind die beiden Protokolle, die dieses Ziel technisch umsetzen, und Keycloak ist die Instanz in der Mitte, die beide spricht. Wer dir «SSO» verkauft, ohne nach den Protokollen deiner Systemlandschaft zu fragen, hat sie nicht angeschaut.
OpenID Connect (OIDC) ist der moderne Standard: schlank, für Web- und Mobile-Anwendungen gebaut, erste Wahl für alles, was neu entsteht. SAML ist der Enterprise-Veteran aus den 2000ern: XML-basiert, schwergewichtiger, dafür in ERP-Systemen, HR-Software und älteren Fachanwendungen fest verdrahtet. Eine realistische Mittelstands-Landschaft braucht beide gleichzeitig – und genau diese Doppelrolle unterscheidet Keycloak von schlankeren Auth-Diensten, die nur OIDC beherrschen.
Die Faustregel für Entscheider: OIDC für alles Neue, SAML überall dort, wo die Gegenseite nichts anderes kann. Ein Alt-System, das nur SAML spricht, ist dabei kein Ausschlusskriterium, sondern Konfigurationsaufwand. Welche Fragen du vor der Festlegung stellen solltest, klärt die Entscheidungshilfe SAML vs. OIDC.
Wann Keycloak passt – und wann nicht
Ehrlich bleibt ehrlich: Ein Managed-IdP ist der richtige Weg, wenn kein Team den Betrieb verantworten kann – Identity ist kritische Infrastruktur, Updates und Verfügbarkeit sind Pflicht, nicht Kür. Für eine einzelne schlanke App reicht oft auch Supabase Auth. Keycloak spielt seine Stärken aus, wenn SSO mehrere Anwendungen verbindet, Verzeichnisse föderiert werden müssen, B2B-Portale feingranulare Rollen brauchen, Compliance Datenhoheit verlangt, oder die MAU-Rechnung des SaaS-IdP zur strategischen Belastung wird.
Die Untergrenze konkret: Eine einzelne Next.js-App mit E-Mail-Login und zwei Rollen rechtfertigt keinen eigenen Identity-Server. Dafür nutzen wir Supabase Auth – im Datenbank-Stack bereits enthalten, ohne zusätzlichen Betriebsaufwand. Der Wechselpunkt kommt mit der zweiten Anwendung, dem ersten Enterprise-Kunden mit SSO-Anforderung oder der ersten Verzeichnis-Anbindung. Welche Optionen davor und dazwischen liegen, vergleicht unser Marktüberblick Keycloak-Alternativen.
Zur Ehrlichkeit gehört auch: Managed-Dienste liefern Nebenleistungen, die Keycloak nicht mitbringt – etwa Anomalie-Erkennung im Login-Verkehr oder die Compliance-Zertifikate des Betreibers. Wer genau diese Funktionen braucht und den US-Datenfluss akzeptiert, fährt mit Auth0 und Co. gut. Der Vergleich lohnt sich also in beide Richtungen.
Der häufigste Keycloak-Fall in unseren Projekten ist das B2B-Kundenportal: Firmenkunden mit eigenen Identitäten, feingranulare Rollen, SSO in die Bestandssysteme. Wie so ein Portal entsteht, beschreibt die Leistungsseite Kundenportal entwickeln lassen; die Architektur dahinter zeigt der Praxisartikel Kundenportal mit SSO und ERP-Anbindung.
Die Kurzformel für den Steuerungskreis: Keycloak lohnt sich, sobald Identität mehr sein muss als ein Login-Formular – wenn sie mehrere Portale verbindet, bestehende Verzeichnisse spiegelt und SSO-Anforderungen von Enterprise-Kunden erfüllbar macht.
Betrieb und Kosten für Entscheider
Betrieb in der EU
Der Betrieb ist bei Identity kein Nebensatz: Fällt der Login aus, stehen alle angeschlossenen Anwendungen still. Verfügbarkeit, Backups, Patches und Monitoring müssen darum geregelt sein, bevor der erste Nutzer migriert. Wir betreiben Keycloak auf EU-Infrastruktur, typischerweise Hetzner in Deutschland: Identitätsdaten bleiben physisch und rechtlich in Europa. Die Optionen vom einzelnen Container bis zum hochverfügbaren Cluster vergleicht Keycloak-Hosting im Überblick.
Für die DSGVO-Bewertung heißt das: kein Drittland-Transfer beim sensibelsten Datenbestand, eine kurze Auftragsverarbeitungskette, Audit-Logs unter deiner Kontrolle. Dieses Argument überzeugt Datenschutzbeauftragte erfahrungsgemäß schneller als jede Standardvertragsklausel eines US-Anbieters. Kommt ein Hosting-Dienstleister ins Spiel, prüfe dessen Sitz und Subprozessoren genauso streng.
Was es kostet
Open Source verschiebt Kosten von Lizenzen zu Projekt und Betrieb: Ein Keycloak-Setup inklusive Integration liegt in unserer Projektklassifikation je nach Umfang zwischen einem fokussierten MVP (8.000–20.000 €) und einer vollständigen Portal-Integration (20.000–60.000 €); der Betrieb auf EU-Infrastruktur bewegt sich im dreistelligen Bereich pro Monat. Was der Stack real kostet, haben wir transparent vorgerechnet: Supabase und Keycloak – was dieser Stack wirklich kostet.
Die vollständige Rechnung inklusive der Posten, die in Anbietervergleichen gern fehlen (Updates, Monitoring, Personentage im Betrieb), schlüsselt der Artikel Was kostet Keycloak? auf.
Wie wir Keycloak mit Supabase und Next.js zu B2B-Webapps kombinieren, zeigt unsere Leistungsseite Supabase-Entwicklung – und für den Gesamtansatz die KI-gestützte Softwareentwicklung.
Nächste Schritte
Stehst du vor der Identity-Entscheidung, empfehle ich drei Schritte. Erstens die Bestandsaufnahme: Welche Anwendungen, welche Nutzergruppen, welche Verzeichnisse sind im Spiel? Zweitens die ehrliche Kostenrechnung deines aktuellen oder geplanten SaaS-IdP über drei Jahre, mit realistischem Nutzerwachstum gerechnet. Drittens die Betriebsfrage: Wer verantwortet Updates, Verfügbarkeit und Monitoring – dein Team oder ein Partner?
Die ersten beiden Schritte schaffst du intern. Für den dritten buche dir ein unverbindliches Beratungsgespräch – am Ende steht eine klare Empfehlung, auch wenn sie «kein Keycloak» lautet. Und wenn du vorher tiefer einsteigen willst: Die hier verlinkten Artikel zu Kosten, Hosting, Alternativen und Protokollen bilden zusammen den vollständigen Entscheidungspfad.
