Keycloak & Auth0 im Health-Kontext: Warum generische IAMs an Digital Health scheitern
Fast jedes DiGA-Team stellt sich früh dieselbe Frage: „Wir kennen Keycloak / Auth0 – können wir das nicht einfach nehmen?" Eine berechtigte Überlegung, denn beide sind ausgereifte Identity-&-Access-Management-Systeme. Die ehrliche Antwort lautet: Für den Login einer Standard-Webanwendung ja – für eine regulierte Digital-Health-Anwendung mit GesundheitsID und BSI-TR-03161-Pflicht stößt man damit an klar benennbare Grenzen.
Dieser Artikel ordnet ein, was Keycloak und Auth0 gut können, wo sie im Gesundheitskontext an Grenzen stoßen und wann ein spezialisiertes Health-IAM die bessere Wahl ist.
Keycloak und Auth0 – was sie gut können
Vorweg, fair eingeordnet: Beide sind exzellente, etablierte Produkte.
Keycloak ist ein leistungsfähiges Open-Source-IAM (heute ein CNCF-Projekt) mit voller Unterstützung für OAuth 2.0, OpenID Connect und SAML. Es ist hochgradig anpassbar, hat keine Lizenzkosten und gibt dir volle Kontrolle – weil du es selbst betreibst.
Auth0 (Teil von Okta) ist ein kommerzielles SaaS-IAM mit hervorragender Developer Experience, vielen vorgefertigten Integrationen und schneller Time-to-Login. Du musst nichts selbst betreiben, zahlst dafür aber typischerweise nutzungsbasiert (nach monatlich aktiven Nutzern).
Für klassische B2B- oder Consumer-Logins sind beide eine gute Wahl. Der Punkt ist nicht „gut oder schlecht", sondern: Sie sind als generische IAMs gebaut, nicht für die spezifischen Anforderungen des deutschen und europäischen Gesundheitswesens.
Die vier Wände, an die generische IAMs im Digital Health stoßen
1. Keine native GesundheitsID- und Föderationsanbindung
Die GesundheitsID basiert auf OpenID Connect – das beherrschen beide. Was aber keiner der beiden mitbringt, ist die sektorale Identity-Föderation der Telematikinfrastruktur: der gematik-Föderationsmaster, die dynamische Anbindung der kassenspezifischen Identity Provider, signierte Entity Statements, JWKS-Hosting und die erweiterten Mechanismen (PKCE, PAR, OIDC Federation). Technisch lässt sich das auf Keycloak oder Auth0 aufsetzen – aber du baust, betreibst und pflegst diese Föderationsschicht dann komplett selbst. Wie aufwendig das ist, haben wir im Beitrag GesundheitsID in eine DiGA integrieren im Detail beschrieben.
2. Kein BSI-TR-03161-Nachweis out-of-the-box
Für die DiGA-Listung ist seit 2025 ein Datensicherheitszertifikat nach BSI TR-03161 Pflicht. Ein generisches IAM liefert dir weder die health-spezifische Konformität noch die Dokumentation, die die Prüfstelle für den Authentisierungs-Teil sehen will. Anforderungen wie Device Binding oder die in O.Auth_4 vorgesehene Anbindung an einen sektoralen Identity Provider musst du selbst umsetzen und in die Zertifizierung einbringen. Was die TR-03161 konkret verlangt, steht im Beitrag BSI TR-03161 für DiGAs.
3. Betrieb, Wartung und sich bewegende Spezifikationen
Bei Keycloak liegt der gesamte Betrieb bei dir: Hochverfügbarkeit, Skalierung, Patching, Härtung – und vor allem das dauerhafte Nachziehen der gematik-Spezifikationen, die sich mit TI 2.0 kontinuierlich weiterentwickeln. Bei Auth0 ist der Basisbetrieb abgenommen, aber die health-spezifische Schicht obendrauf bleibt euer Code, den ihr ebenfalls pflegen müsst. In beiden Fällen entsteht ein Wartungsaufwand, der nach dem Go-Live nicht verschwindet, sondern bleibt – und an Spec-Stichtagen zum kritischen Pfad wird.
4. „Kostenlos" vs. Total Cost of Ownership – und Datensouveränität
Keycloaks Lizenz ist kostenlos, die Gesamtkosten sind es nicht: Betrieb, Sicherheit, Compliance-Nachweise und Entwicklungszeit für die Föderationsschicht summieren sich schnell zu einem fünf- bis sechsstelligen Initial- plus laufenden Aufwand. Auth0 wiederum skaliert mit der Nutzerzahl, was bei wachsender DiGA teuer werden kann. Hinzu kommt bei einem US-Mutterkonzern die Frage der Datensouveränität: Auth0 bietet zwar EU-Datenhaltung, dennoch wägen viele Health-Teams die Implikationen (DSGVO, Schrems II, Datenhoheit) bewusst ab.
Wann ein generisches IAM trotzdem die richtige Wahl ist
Damit es ehrlich bleibt: Es gibt klare Fälle, in denen Keycloak oder Auth0 völlig ausreichen – und ein spezialisiertes Health-IAM überdimensioniert wäre. Etwa für interne Tools und Mitarbeiter-Logins, für Anwendungen ohne GesundheitsID-, TI- oder TR-03161-Bezug, oder für ein Produkt, das (noch) keine sensiblen Gesundheitsdaten im regulierten Sinn verarbeitet. Wer keinen Berührungspunkt mit der Telematikinfrastruktur hat, gewinnt durch ein Health-IAM wenig.
Die Entscheidung kippt genau dann, wenn GesundheitsID, TI-Anbindung oder die TR-03161-Zertifizierung ins Spiel kommen – also bei praktisch jeder DiGA und zunehmend bei Patientenportalen und Telemedizin.
Was eine Health-IAM-Alternative anders macht
Ein spezialisiertes Health-IAM wie azuma doa deckt genau die Schicht ab, die bei generischen IAMs offenbleibt: die GesundheitsID-Föderation (über azuma mimoto), Device Binding, Passkeys und FIDO2-Biometrie, sichere Session- und Token-Verwaltung sowie die zugehörige TR-03161-Dokumentation – out-of-the-box und ohne dass ihr die Föderation selbst baut oder die Spec-Updates selbst nachzieht.
Der praktische Unterschied zeigt sich in der Zertifizierung: Zum Zeitpunkt dieses Beitrags haben bereits mehrere azuma-Kunden den Zertifizierungsprozess nach BSI TR-03161 mit azuma doa als eingesetztem IAM erfolgreich durchlaufen – nach unserem Kenntnisstand als bislang einziger Third-Party-SaaS-IAM in DiGA-Projekten. Genau dieser fertige, nachweisbare Identitäts-Baustein ist das, was Keycloak und Auth0 im Health-Kontext nicht liefern.
Entscheidungshilfe
Eine schnelle Orientierung:
- Brauchst du GesundheitsID / TI-Anbindung? Ja → generisches IAM bedeutet Eigenbau der Föderation. Nein → Keycloak/Auth0 sind eine valide Option.
- Steht eine BSI-TR-03161-Zertifizierung an? Ja → ein konformer Health-Baustein verkleinert Scope und Risiko erheblich.
- Wie wichtig sind Betriebsfreiheit und Datensouveränität? Hoch → ein spezialisierter EU-SaaS nimmt euch Betrieb und Spec-Pflege ab.
- Wie entwickelt sich eure Nutzerzahl? Stark wachsend → nutzungsbasierte Modelle früh gegen planbare Health-IAM-Tarife rechnen.
Häufige Fragen
Kann ich Keycloak für eine DiGA verwenden?
Technisch ja – Keycloak beherrscht OIDC. Die GesundheitsID-Föderation und die BSI-TR-03161-Konformität musst du allerdings selbst aufbauen, zertifizieren und dauerhaft mit den gematik-Spezifikationen pflegen. Das ist der eigentliche Aufwand, nicht der Login selbst.
Ist Auth0 für Gesundheitsdaten DSGVO-konform?
Auth0 bietet EU-Datenhaltung und lässt sich DSGVO-konform betreiben. Viele Health-Teams wägen aber zusätzlich die Datensouveränität bei einem US-Mutterkonzern sowie die fehlende native Unterstützung deutscher Health-Standards (gematik, GesundheitsID, TI) ab.
Was ist der Unterschied zwischen einem generischen IAM und einem Health-IAM?
Ein generisches IAM unterstützt breite Standards wie OIDC und SAML. Ein Health-IAM bringt darüber hinaus die gesundheitsspezifischen Anforderungen nativ mit: GesundheitsID-Föderation, TI-Anbindung, TR-03161-Konformität und die zugehörigen Nachweise.
Lohnt sich der Wechsel von Keycloak oder Auth0?
Das hängt vom Scope ab. Je näher ihr an GesundheitsID, TI-Anbindung oder TR-03161-Zertifizierung kommt, desto eher überwiegt der Nutzen eines spezialisierten Health-IAM – durch geringeren Eigenbau, weniger Wartung und einen schnelleren Zertifizierungsweg.
Du evaluierst gerade dein IAM für eine DiGA? Sprich mit unserem Team oder hol dir einen kostenlosen Developer-Zugang und vergleiche selbst, wie azuma doa die GesundheitsID- und TR-03161-Lücke generischer IAMs schließt.