Keycloak oder Authentik in Deutschland betreiben lassen? WZ-IT übernimmt Installation, Hosting und Betrieb für Keycloak, Authentik und ZITADEL: Updates, Backups, Monitoring und die Anbindung Ihrer Anwendungen. Erstgespräch vereinbaren
Wer nach einer Keycloak-Alternative sucht, hat meist eine konkrete Reibung: Altanwendungen ohne OIDC, Kunden als Mandanten, ein Lizenzthema oder den Betrieb. Dieser Beitrag legt Entscheidungsregeln vor und belegt sie mit Lizenzdateien und Herstellerdokumentation, Stand 29. Oktober 2026.
Hinweis zur Einordnung: WZ-IT betreibt Keycloak und Authentik als Dienstleistung. Zu ZITADEL und den weiteren genannten Projekten stehen hier nur Angaben aus den öffentlichen Quellen. Den direkten Vergleich der beiden Projekte Authentik und ZITADEL enthält der bestehende Beitrag Authentik vs. Zitadel; er wird hier nicht wiederholt. Dieser Beitrag nimmt Keycloak als Ausgangspunkt.
Inhaltsverzeichnis
- Kurz beantwortet
- Basisdaten im Überblick
- Lizenzen aus den LICENSE-Dateien
- Standards und Protokolle
- Mandantenfähigkeit
- Betrieb und Ressourcen
- Erweiterbarkeit und Konfigurationsmodell
- Weitere Alternativen
- Migration von Keycloak
- Verbreitete Irrtümer
- Stand und Methodik
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
- Quellen
Kurz beantwortet
| Wenn das zutrifft | Dann prüfen |
|---|---|
| Standard-Anwendungen mit OIDC und SAML, vorhandene Keycloak-Konfiguration, Team kennt Keycloak | Keycloak behalten; ein Wechsel sollte einen konkreten Mangel beheben. |
| Altanwendungen ohne OIDC/SAML (LDAP, RADIUS, Header-Authentifizierung) | Authentik: LDAP-, RADIUS- und Proxy-Provider sind Teil der Dokumentation. |
| Kunden als getrennte Organisationen mit eigenen Domains und Onboarding per API | ZITADEL (Organisationen, virtuelle Instanzen) oder Keycloak mit Organizations bzw. einem Realm je Kunde. |
| AGPL-3.0 ist für das Vorhaben nicht akzeptabel | Keycloak (Apache-2.0), Authentik (MIT, Enterprise-Verzeichnis ausgenommen), Ory, Casdoor, Dex, Authelia (Apache-2.0). |
| Anwendungen im Cluster sollen sich an bestehende Verzeichnisse oder externe Anbieter anbinden | Dex als OIDC-Vermittler mit Connectors. |
| Zugriffsschutz und MFA hinter einem Reverse Proxy | Authelia. |
| Eigene Anmelde-Oberfläche in einem Produkt | Ory Kratos (Identitäten) mit Ory Hydra (OAuth 2.0/OIDC). |
| Kommerzielles Produkt statt Open Source | FusionAuth (Kundenlizenz, Community-Edition kostenlos im Self-Hosting). |
Die Tabelle gibt Prüfrichtungen vor, keine Empfehlung ohne Kenntnis der Anwendungen. Die Begründungen stehen in den folgenden Abschnitten.
Basisdaten im Überblick
| Keycloak | Authentik | ZITADEL | |
|---|---|---|---|
| Aktuelles Release | 26.8.1 (13.10.2026) | 2026.8.5 (21.10.2026) | v4.20.0 (22.10.2026) |
| GitHub-Sterne (gerundet) | 37.600 | 26.200 | 15.500 |
| Lizenz laut Repository | Apache-2.0 | MIT mit Ausnahmen | AGPL-3.0-only mit Ausnahmen |
| Konfigurationsmodell | Realms, Clients, Flows | Flows, Stages, Provider, Applications | Instanzen, Organisationen, Projekte, Anwendungen |
Quelle der Zahlen sind die GitHub-API der drei Repositories und die dortigen Releases, abgerufen am 29. Oktober 2026 (Keycloak, Authentik, ZITADEL). Sterne sagen nichts über Eignung aus; sie zeigen nur die Verbreitung.
Lizenzen aus den LICENSE-Dateien
| Software | Lizenz | Ausnahmen und Hinweise |
|---|---|---|
| Keycloak | Apache-2.0 | keine Ausnahmen in der Datei |
| Authentik | MIT | Inhalte unter authentik/enterprise/ stehen unter der Enterprise-Lizenz (Produktivbetrieb nur mit Subscription); website/ unter CC BY-SA 4.0; clientseitiges JavaScript unter MIT Expat. GitHub zeigt deshalb NOASSERTION. |
| ZITADEL | AGPL-3.0-only (seit v3) | Apache-2.0 für proto/ und apps/docs/, MIT für apps/login/, packages/zitadel-client/ und packages/zitadel-proto/ laut LICENSING.md |
| Ory Kratos, Ory Hydra | Apache-2.0 | LICENSE-Datei des jeweiligen Repositorys |
| Casdoor | Apache-2.0 | LICENSE-Datei des Repositorys |
| Dex | Apache-2.0 | LICENSE-Datei des Repositorys |
| Authelia | Apache-2.0 | LICENSE-Datei des Repositorys |
| FusionAuth | kein Open Source | Customer License Agreement; Community-Edition für das Self-Hosting kostenlos laut Preisseite |
Zwei Punkte werden häufig verwechselt. Erstens: Authentik ist im Kern MIT-lizenziert, die Enterprise-Funktionen liegen in einem getrennten Verzeichnis unter einer Lizenz, die den Produktivbetrieb an ein Abonnement bindet. Laut Preisseite gehören dazu unter anderem die Integrationen für Microsoft Entra ID und Google Workspace, Client-Zertifikat-Authentifizierung (mTLS), erweitertes Audit-Logging und Radius EAP-TLS; der Plan Enterprise kostet dort 5 US-Dollar pro Nutzer und Monat bei jährlicher Abrechnung (abgerufen am 29.10.2026). Zweitens: ZITADEL wechselte mit Version 3 von Apache-2.0 auf AGPL-3.0, angekündigt am 13. März 2025. Die Lizenzierungsrichtlinie des Projekts hält fest, dass die Prüfung der AGPL-Pflichten beim Nutzer liegt und eine kommerzielle Lizenz auf Anfrage möglich ist. Die AGPL knüpft Pflichten an die Veränderung der Software und an das Anbieten der veränderten Version über ein Netzwerk; ob ein konkretes Vorhaben betroffen ist, klärt die Rechtsberatung.
Standards und Protokolle
| Keycloak | Authentik | ZITADEL | |
|---|---|---|---|
| OIDC / OAuth 2.0 | ja | ja, OpenID-zertifiziert für OIDC laut Preisseite | ja |
| SAML 2.0 | ja | SAML-Provider und SAML-Source | ja, als IdP (Doku) |
| SCIM 2.0 (Nutzer von außen anlegen lassen) | SCIM-API für Nutzer und Gruppen, je Realm einzuschalten (unterstützt seit 26.8, in 26.7 Preview) | SCIM-Source | SCIM v2.0 (Doku) |
| SCIM 2.0 (Nutzer in Anwendungen schreiben) | in der Doku nicht gefunden | SCIM-Provider | in der Doku nicht gefunden |
| LDAP-Verzeichnis für Altanwendungen bereitstellen | in der Doku nicht gefunden (Keycloak bindet LDAP/AD als Quelle an) | LDAP-Provider | in der Doku nicht gefunden |
| RADIUS, Proxy-Provider | in der Doku nicht gefunden | RADIUS-Provider, Proxy-Provider, RAC-Provider | in der Doku nicht gefunden |
Die Protokollzeile entscheidet selten. Alle drei sprechen OIDC und SAML. Den Unterschied machen die Zeilen darunter: Wer Nutzer in angebundene Anwendungen provisionieren oder Altanwendungen über LDAP, RADIUS oder einen Proxy anbinden muss, findet diese Bausteine nur bei Authentik dokumentiert. Die SCIM-Schnittstelle von Keycloak steht in der Feature-Liste und in der Admin-Dokumentation von 26.8.
Mandantenfähigkeit
- Keycloak: Ein Realm ist laut Dokumentation ein gegen andere Realms isolierter Raum mit eigenen Nutzern, Clients, Rollen und Gruppen. Seit Keycloak 26.0 bilden Organizations Kunden oder Partner innerhalb eines Realms ab: Mitglieder, Gruppen, Einladungslinks, Domains, gemeinsam nutzbare Identity Provider und organisationsspezifische Claims. Das Feature ist je Realm einzuschalten.
- Authentik: Brands gelten je Domain oder Domain-Wildcard und steuern Erscheinungsbild und Standard-Flows der Instanz. Die Preisseite nennt Support für Multi-Instance-Deployments als Merkmal von Enterprise Plus. Für harte Mandantentrennung kommt nach unserer Einschätzung je Mandant eine eigene Instanz in Betracht.
- ZITADEL: Die Dokumentation beschreibt die Organisation als Gefäß für Projekte und Nutzer, vergleichbar mit einem Mandanten. Darüber liegen virtuelle Instanzen, die sich über die System-API anlegen lassen, mit eigener Domain.
Daraus folgt eine Regel: Je stärker Kunden als eigene Einheiten mit eigener Domain und Verwaltung auftreten sollen, desto eher spricht das Mandantenmodell für ZITADEL oder für Keycloak mit Organizations. Für eine einzelne Organisation mit vielen Anwendungen ist das Merkmal ohne Gewicht.
Betrieb und Ressourcen
| Keycloak | Authentik | ZITADEL | |
|---|---|---|---|
| Angabe des Herstellers | 1250 MB RAM je Pod als Basis, inklusive Realm-Caches und 10.000 Sessions; 1 vCPU je 15 Passwort-Logins pro Sekunde (Sizing-Guide) | Host mit mindestens 2 CPU-Kernen und 2 GB RAM für die Docker-Compose-Installation, ausgelegt für Tests und kleine Produktivsetups (Doku) | Server etwa 512 MB RAM und weniger als ein CPU-Kern, für Spitzen beim Passwort-Hashing werden 4 CPU-Kerne empfohlen; Datenbank etwa ein Kern je 100 Anfragen pro Sekunde und 4 GB RAM je Kern (Doku) |
| Kubernetes | Operator | Helm-Chart | Helm-Chart |
Die drei Angaben haben unterschiedliche Messgrundlagen: Keycloak nennt den Bedarf eines Pods mit Caches und Sessions, Authentik die Mindestgröße eines Hosts mit allen Diensten, ZITADEL den Server ohne Datenbank. Eine Rangfolge nach Ressourcenverbrauch lässt sich daraus nicht ableiten. Die Aussage, eine Alternative brauche "weniger Ressourcen", gilt erst nach einem Test mit der eigenen Last, insbesondere der Zahl der Passwort-Logins, denn Keycloak verbringt laut Sizing-Guide den größten Teil der CPU-Zeit mit dem Passwort-Hashing.
Für den laufenden Betrieb zählen Updates. Welche Breaking Changes ein Keycloak-Update mitbringt, beschreibt die Upgrade-Checkliste für Keycloak 26.8.
Erweiterbarkeit und Konfigurationsmodell
- Keycloak: Eigene Logik läuft als Java-SPI (Service Provider Interfaces), Themes passen die Oberfläche an. Die Konfiguration besteht aus Realm, Clients, Authentication Flows und Mappern.
- Authentik: Anmeldeabläufe werden aus Flows und Stages zusammengesetzt, Sonderfälle als Expression Policies in Python. Blueprints legen die Konfiguration als Dateien ab und können aus einer Instanz exportiert werden.
- ZITADEL: Actions verändern das Verhalten an bestimmten Ereignissen. Die Verwaltung folgt der Struktur Instanz, Organisation, Projekt, Anwendung.
Die Wahl hängt hier an der vorhandenen Kompetenz: Ein Team mit Java-Erfahrung schreibt SPIs, ein Team mit Python-Erfahrung Expression Policies. Eine allgemeine Aussage zur "besseren Admin-Oberfläche" belegen die Quellen nicht.
Weitere Alternativen
| Projekt | Aufgabe laut README | Lizenz | Release (29.10.2026) |
|---|---|---|---|
| Ory Kratos | API-first Identitäts- und Nutzerverwaltung | Apache-2.0 | v26.2.0 (20.03.2026) |
| Ory Hydra | OpenID-zertifizierter OAuth-2.0- und OIDC-Server, ausdrücklich ohne Nutzerverwaltung | Apache-2.0 | v26.2.0 (20.03.2026) |
| Casdoor | SSO- und Authentifizierungsserver mit Web-Konsole: OAuth 2.0, OIDC, SAML 2.0, CAS, LDAP, SCIM 2.0, WebAuthn, TOTP | Apache-2.0 | v4.24.0 (25.10.2026) |
| Dex | OIDC-Vermittler, der Anmeldungen über Connectors an LDAP, SAML und externe Anbieter weiterreicht | Apache-2.0 | v2.46.1 (21.10.2026) |
| Authelia | Authentifizierungs- und Autorisierungsserver mit Zwei-Faktor und SSO über ein Web-Portal, als Begleiter für Reverse Proxys; OpenID-zertifiziert für mehrere OP-Profile | Apache-2.0 | v4.39.28 (17.09.2026) |
| FusionAuth | kommerzielles Produkt, Community-Edition kostenlos im Self-Hosting | Customer License Agreement | nicht geprüft |
Ory ist ein Baukasten: Kratos und Hydra decken zusammen Nutzer und Token-Ausstellung ab, die Anmelde-Oberfläche entsteht im eigenen Produkt. Wer eine fertige Verwaltungsoberfläche für Administratoren erwartet, vergleicht eher mit Keycloak, Authentik, ZITADEL oder Casdoor. Dex und Authelia lösen Teilaufgaben und ersetzen Keycloak nur dort, wo diese Teilaufgabe der gesamte Bedarf ist.
Migration von Keycloak
| Bestandteil | Quelle in Keycloak | Zielsystem |
|---|---|---|
| Realm-Einstellungen, Clients, Rollen, Gruppen | Export über kc.sh export; die Admin Console exportiert nur teilweise (Einstellungen, Clients, Rollen, Gruppen, keine Nutzer) (Doku) |
Authentik: Applications und Provider neu anlegen, Konfiguration als Blueprint ablegen. ZITADEL: Projekte und Anwendungen anlegen; das Migrationswerkzeug behandelt Nutzer, überträgt laut README keine Rollen und Gruppen. |
| Nutzer | kc.sh export --users realm_file schreibt Nutzer in die Realm-Datei |
ZITADEL: zitadel-tools migrate keycloak erzeugt die Importdatei, Import über POST /admin/v1/import (Anleitung) |
| Passwort-Hashes | Keycloak hasht mit Argon2 (Standard ohne FIPS), pbkdf2-sha512 (FIPS-Standard), pbkdf2-sha256 oder dem veralteten pbkdf2 (Doku) | ZITADEL: Import mit Hash und Verifier (Doku); das Keycloak-Werkzeug verarbeitet laut README nur die pbkdf2-Familie, ignoriert andere Anmeldedaten wie TOTP und setzt alle Nutzer auf aktiv. Für Argon2-Hashes ist der Weg nicht dokumentiert. Authentik: Seit 2026.5 Import vorgehashter Django-Passwörter über das Blueprint-Feld password_hash oder die API set_password_hash (Doku); die Umwandlung von Keycloak-Hashes in dieses Format ist nicht beschrieben. Alternativen sind Passwort-Reset per Recovery-Flow oder der alte Keycloak als OAuth- bzw. SAML-Source während einer Übergangszeit. |
| MFA-Faktoren | TOTP und Passkeys | WebAuthn-Credentials sind an die RP-ID, also die Domain, gebunden (W3C WebAuthn); bei geänderter Domain ist eine neue Registrierung nötig. Für TOTP ist die Übernahme je Zielsystem und Werkzeug zu prüfen. |
| Anwendungen | Issuer /realms/<realm> |
Authentik: Endpunkte je Application unter /application/o/<slug>/ (Doku). ZITADEL: Discovery unter der Instanz-Domain (Doku). |
Der kritische Pfad ist der Issuer. Jede Anwendung, die ID-Token prüft, muss auf die neue Issuer-URL und neue Schlüssel umgestellt werden. Das ist die eigentliche Migrationsarbeit, nicht der Nutzerexport. Für Anwendungen, die Nutzer über den sub-Claim verknüpfen, gilt: Die Werte entstehen im Zielsystem neu, sofern sie nicht gezielt übernommen werden; vor dem Umschalten ist ein Mapping einzuplanen. Dieser Punkt ist eine Schlussfolgerung aus dem OIDC-Modell und kein Zitat aus den Herstellerdokumentationen.
Praktische Reihenfolge: Zielsystem parallel aufbauen, eine unkritische Anwendung zuerst umstellen, den alten Keycloak als Quelle oder Rückfall behalten, erst danach die übrigen Anwendungen umstellen. Wie SSO und MFA für den Fernzugriff und für KI-Oberflächen aussehen, zeigen SSO & MFA für das Fernzugriffs-Portal, NetBird mit Authentik oder Keycloak und Open WebUI SSO einrichten.
Verbreitete Irrtümer
- "Keycloak ist nicht mandantenfähig." Realms gibt es seit Langem, Organizations sind seit Keycloak 26.0 ein unterstütztes Feature. Wer das Gegenteil liest, liest einen älteren Stand.
- "Authentik ist komplett MIT." Der Kern ja;
authentik/enterprise/nicht. - "ZITADEL ist Apache-2.0." Das galt bis Version 2. Seit Version 3 ist das Repository AGPL-3.0-only, mit Apache- und MIT-Ausnahmen für einzelne Verzeichnisse.
- "Die Alternative braucht weniger Ressourcen." Die Herstellerangaben messen Verschiedenes (siehe oben); belastbar ist nur ein Test mit eigener Last.
- "Mit dem Wechsel entfällt der Betriebsaufwand." Updates, Backups, Monitoring und die Umstellung der Anwendungen bleiben bei jedem Identity Provider bestehen.
Stand und Methodik
Stand: 29. Oktober 2026. Datenbasis sind die LICENSE-Dateien und LICENSING.md der Repositories von Keycloak, Authentik und ZITADEL, die GitHub-API (Version, Sterne, erkannte Lizenz) für alle genannten Projekte, die Dokumentation der drei Hauptprojekte (Version 26.8, 2026.8, v4.20), die READMEs der weiteren Projekte sowie die Preis- und Lizenzseiten von Authentik und FusionAuth. Aussagen mit "in der Doku nicht gefunden" sind Dokumentationsbefunde, keine Tests; fehlende Dokumentation beweist nicht, dass ein Merkmal fehlt. Ressourcenangaben sind Herstellerangaben mit unterschiedlicher Messgrundlage.
Die Aussage zum sub-Claim bei der Migration und die Praxisreihenfolge sind Schlussfolgerungen aus den Standards und eigener Erfahrung, nicht aus den zitierten Quellen. FusionAuth wurde nur anhand von Preisseite und Lizenztext eingeordnet, nicht funktional.
Tabellen und Zahlen dürfen mit Quellenangabe und Link auf diesen Beitrag weiterverwendet werden.
Unser Vorgehen bei WZ-IT
WZ-IT betreibt Keycloak, Authentik und ZITADEL als Hosting- und Betriebsangebot: Installation, Hosting in Deutschland oder in Ihrer eigenen Umgebung, Backups und Wartung, Migration bestehender Instanzen. Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level. Funktionen, die Authentik nur mit Enterprise-Lizenz bereitstellt, etwa die Integrationen für Microsoft Entra ID und Google Workspace, benötigen einen Lizenzschlüssel des Herstellers; der Lizenzvertrag wird mit dem Hersteller geschlossen, bei der Auswahl unterstützt WZ-IT. Die Entscheidung zwischen den Systemen fällt anhand der Anwendungen, Protokolle und des Mandantenmodells, wie oben beschrieben.
Weiterführende Guides
- Authentik vs. Zitadel, der direkte Vergleich der beiden Projekte.
- Keycloak 26.8 Upgrade, Checkliste mit Breaking Changes.
- SSO & MFA für das Fernzugriffs-Portal, Protokolle und Faktoren im Überblick.
- NetBird mit Authentik oder Keycloak, Anbindung des VPN an den Identity Provider.
- Open WebUI SSO einrichten, Anmeldung an der KI-Oberfläche über OIDC.
- Keycloak Betrieb und Hosting, Authentik Betrieb und Hosting und ZITADEL Hosting.
Keycloak behalten, ersetzen oder erweitern? Wir ordnen Anwendungen, Protokolle und Mandantenmodell ein und betreiben Keycloak und Authentik in Deutschland. Termin vereinbaren
Quellen
- Keycloak, Repository
- Keycloak, LICENSE.txt
- Keycloak Docs, Server Administration (26.8)
- Keycloak Docs, Server Developer Guide
- Keycloak, Features
- Keycloak, Release Notes
- Keycloak, Importing and exporting realms
- Keycloak, Concepts for sizing CPU and memory resources
- Keycloak, Operator Installation
- authentik, Repository
- authentik, LICENSE
- authentik, Enterprise-LICENSE
- authentik, Pricing
- authentik Docs, Docker Compose
- authentik Docs, Kubernetes
- authentik Docs, OAuth2 Provider
- authentik Docs, SCIM Provider
- authentik Docs, SCIM Source
- authentik Docs, LDAP Provider
- authentik Docs, Brands
- authentik Docs, Automated install (Passwort-Hash-Import)
- authentik, Release 2026.5
- authentik Docs, Flows
- authentik Docs, Expression Policies
- authentik Docs, Blueprints
- ZITADEL, Repository
- ZITADEL, LICENSE
- ZITADEL, LICENSING.md
- ZITADEL, v3 Announcement
- ZITADEL Docs, Organizations
- ZITADEL Docs, Instances
- ZITADEL Docs, Production Setup
- ZITADEL Docs, Kubernetes
- ZITADEL Docs, Migrate from Keycloak
- ZITADEL Docs, Migrate users
- zitadel-tools, Keycloak migration README
- ZITADEL Docs, SCIM v2.0
- ZITADEL Docs, SAML
- ZITADEL Docs, OIDC Endpoints
- ZITADEL Docs, Actions
- Ory Kratos, Repository
- Ory Hydra, Repository
- Casdoor, Repository
- Dex, Repository
- Authelia, Repository
- FusionAuth, Customer License Agreement
- FusionAuth, Pricing
- W3C, Web Authentication Level 3
