5 Fallen im Keycloak-Eigenbetrieb – aus der Praxis

Keycloak ist mächtig – protokollstark, ausgereift, von einer aktiven Community weiterentwickelt. Genau deshalb kommt kaum jemand daran vorbei, der sich mit modernem Identity & Access Management beschäftigt. Aber „mächtig“ heißt eben auch „mächtig komplex“, und der Eigenbetrieb fühlt sich in der Praxis oft anders an, als man beim ersten Aufsetzen denkt.

Hier sind fünf Muster, die ich in Kundengesprächen, Migrationen und Architektur-Reviews immer wieder sehe – nicht als Kritik an Keycloak selbst, sondern als das, was zwischen „technisch möglich“ und „im Alltag beherrschbar“ liegt.

1. Auth-Flows werden als Einmalprojekt behandelt, nicht als Wartungslast

Der Klassiker: Jemand konfiguriert einen Login-Flow – sagen wir, MFA mit einer IP-Ausnahme fürs interne Netzwerk. Was dabei oft unterschätzt wird: Änderungen an Auth-Flows sind in Keycloak sofort live. Es gibt keinen Entwurfsmodus, keine Staging-Umgebung innerhalb der Oberfläche. Ein Konfigurationsfehler sperrt im Zweifel alle Nutzer aus – sofort und ohne Vorwarnung.

Das Problem zeigt sich oft erst später. Sechs Monate danach soll jemand anderes eine Kleinigkeit ändern – und steht vor einem Flow-Graphen, den er nicht selbst gebaut hat und der nirgends dokumentiert ist. Was als einmaliges Setup gedacht war, wird zur stillen Wartungslast, die niemand einplant, bis sie fällig wird.

2. Konditionelle MFA wird pro Projekt neu erfunden

Eine der ersten Fragen in nahezu jedem Enterprise-Gespräch: Können wir MFA für Nutzer im Firmennetzwerk aussetzen und außerhalb erzwingen? Keycloak hat grundsätzlich ein Konzept für Bedingungen in Auth-Flows, aber die mitgelieferten Conditions sind limitiert. Eine native Bedingung für den Netzwerkkontext, etwa IP-Range oder „internes Netz vs. extern", gibt es nicht. Wer sie umsetzen will, kommt an einer eigenen SPI-Implementierung nicht vorbei – einem Custom Condition Authenticator, der als Extension gebaut, deployt und über Keycloak-Updates hinweg gepflegt werden muss.

Der Fehler passiert nicht bei der Umsetzung selbst, sondern danach: Jedes Team, das ich kenne, hat dieses Problem für sich allein gelöst. Es gibt keinen Standard dafür, keine gemeinsame Basis – nur denselben Bedarf, x-fach individuell nachgebaut, mit x-fachem Wartungsaufwand.

3. Kein Lifecycle-Konzept – bis Compliance danach fragt

Keycloak kennt von Haus aus kein Konzept für inaktive Nutzerkonten. Keine automatische Erkennung, keine gestufte Deaktivierung, keine Löschroutine. Für viele Teams ist das lange kein Thema – bis ein NIS2- oder ISO-27001-Audit konkret danach fragt.

Genau dann wird aus einem Feature, das man in Ruhe hätte mitdenken können, ein Zeitdruck-Projekt: Wie identifizieren wir inaktive Konten rückwirkend? Wie dokumentieren wir das für den Prüfer? Compliance-Anforderungen wie diese lassen sich vorbereiten – aber nur, wenn man sie einplant, bevor sie akut werden, nicht danach.

4. Branding bedeutet Softwareentwicklung – bei jeder Änderung

Was viele erst im laufenden Betrieb merken: Branding in Keycloak ist kein einmaliges Setup, sondern eine Dauerlast. Jede Anpassung an Login-Strecken – ob Logo, Farben oder Texte – ist ein Code-Change mit Build und Deployment. Keycloak-Updates können bestehende Templates brechen – insbesondere bei größeren Versionssprüngen ist manuelle Nacharbeit die Regel, nicht die Ausnahme.

5. SCIM-Reifegrad wird überschätzt

SCIM ist der Standard, über den HR-Systeme wie Entra ID Nutzer automatisiert anlegen, aktualisieren und deaktivieren. In aktuellen Keycloak-Versionen gibt es SCIM inbound nur als Technology Preview (Stand Mitte 2026) – vom Upstream-Projekt selbst nicht für den Produktivbetrieb empfohlen. SCIM outbound, also das aktive Ausspielen von Nutzerdaten an andere Systeme, fehlt komplett.

Der Fehler: Integrationsprojekte werden auf Basis dieser Preview-Funktionalität geplant, weil sie im ersten Test funktioniert. Im Produktivbetrieb zeigt sich dann, dass „funktioniert im Test“ und „produktionsreif“ zwei unterschiedliche Dinge sind – mit entsprechendem Nacharbeitsaufwand, wenn das HR-Onboarding schon darauf aufbaut.

Was das gemeinsam hat

Keiner dieser fünf Punkte ist ein Bug oder eine Schwäche von Keycloak. Es sind bewusste Grenzen eines Open-Source-Projekts, das eine Identity Engine liefert – nicht das Produkt drumherum: Administration, Betriebsprozesse, Compliance-Tooling, Nutzererfahrung.

Wer Keycloak selbst betreibt, kann jeden einzelnen dieser Punkte lösen. Die Frage ist nur, ob man das für sich allein tun will – oder ob man diesen Teil der Arbeit dorthin gibt, wo er schon gelöst ist, um sich auf die Architektur zu konzentrieren, die wirklich unternehmensspezifisch ist.