Keycloak & Auth0 in the Health Context: Why Generic IAMs Fail at Digital Health
Almost every DiGA team faces the same question early on: "We know Keycloak / Auth0 – can't we just use that?" A valid consideration, as both are mature Identity & Access Management systems. The honest answer is: For the login of a standard web application, yes – for a regulated digital health application with GesundheitsID and BSI TR-03161 requirements, you will hit clearly identifiable limits.
This article categorizes what Keycloak and Auth0 do well, where they reach their limits in the healthcare context, and when a specialized Health IAM is the better choice.
Keycloak and Auth0 – What They Do Well
First off, to be fair: Both are excellent, established products.
Keycloak is a powerful open-source IAM (now a CNCF project) with full support for OAuth 2.0, OpenID Connect, and SAML. It is highly customizable, has no licensing costs, and gives you full control – because you operate it yourself.
Auth0 (part of Okta) is a commercial SaaS IAM with outstanding Developer Experience, many pre-built integrations, and a fast time-to-login. You don't have to operate anything yourself, but you typically pay usage-based (by monthly active users).
For classic B2B or consumer logins, both are a good choice. The point is not "good or bad", but rather: They are built as generic IAMs, not for the specific requirements of the German and European healthcare systems.
The Four Walls Generic IAMs Hit in Digital Health
1. No Native GesundheitsID and Federation Connection
The GesundheitsID is based on OpenID Connect – both master this. But what neither brings out-of-the-box is the sectoral identity federation of the Telematics Infrastructure: the gematik federation master, the dynamic connection of the health insurance-specific Identity Providers, signed Entity Statements, JWKS hosting, and the extended mechanisms (PKCE, PAR, OIDC Federation). Technically, this can be built on top of Keycloak or Auth0 – but then you build, operate, and maintain this federation layer completely yourself. We described in detail how complex this is in our post Integrating GesundheitsID into a DiGA.
2. No BSI TR-03161 Proof Out-of-the-Box
For the DiGA listing, a data security certificate according to BSI TR-03161 has been mandatory since 2025. A generic IAM provides neither the health-specific compliance nor the documentation that the auditing body wants to see for the authentication part. Requirements like Device Binding or the connection to a sectoral Identity Provider required by O.Auth_4 must be implemented by you and brought into the certification. What TR-03161 specifically demands is explained in our post BSI TR-03161 for DiGAs.
3. Operations, Maintenance, and Moving Specifications
With Keycloak, the entire operation is up to you: high availability, scaling, patching, hardening – and above all, continuously adopting the gematik specifications, which are constantly evolving with TI 2.0. With Auth0, the basic operation is covered, but the health-specific layer on top remains your code, which you also have to maintain. In both cases, a maintenance effort arises that does not disappear after the go-live, but remains – and becomes the critical path on spec deadlines.
4. "Free" vs. Total Cost of Ownership – and Data Sovereignty
Keycloak's license is free, but the total costs are not: Operations, security, compliance proofs, and development time for the federation layer quickly add up to a five- to six-figure initial plus ongoing effort. Auth0, on the other hand, scales with the number of users, which can become expensive for a growing DiGA. Additionally, with a US parent company, the question of data sovereignty arises: Auth0 does offer EU data hosting, but many health teams deliberately weigh the implications (GDPR, Schrems II, data sovereignty).
When a Generic IAM is Still the Right Choice
To be honest: There are clear cases where Keycloak or Auth0 are completely sufficient – and a specialized Health IAM would be oversized. For example, for internal tools and employee logins, for applications without a connection to GesundheitsID, TI, or TR-03161, or for a product that does not (yet) process sensitive health data in the regulated sense. If you have no touchpoints with the Telematics Infrastructure, you gain little from a Health IAM.
The decision tips precisely when GesundheitsID, TI connection, or the TR-03161 certification come into play – which is the case for practically every DiGA and increasingly for patient portals and telemedicine.
What a Health IAM Alternative Does Differently
A specialized Health IAM like azuma doa covers exactly the layer that remains open with generic IAMs: the GesundheitsID federation (via azuma mimoto), Device Binding, Passkeys and FIDO2 biometrics, secure session and token management, as well as the associated TR-03161 documentation – out-of-the-box and without you having to build the federation yourself or implement the spec updates yourself.
The practical difference becomes apparent in the certification: At the time of this post, several azuma customers have already successfully passed the certification process according to BSI TR-03161 with azuma doa as their employed IAM – to our knowledge, currently the only third-party SaaS IAM in DiGA projects. Exactly this ready-made, verifiable identity building block is what Keycloak and Auth0 do not deliver in the health context.
Decision Guide
A quick orientation:
- Do you need GesundheitsID / TI connection? Yes → generic IAM means building the federation yourself. No → Keycloak/Auth0 are a valid option.
- Is a BSI TR-03161 certification pending? Yes → a compliant health building block significantly reduces scope and risk.
- How important are operational freedom and data sovereignty? High → a specialized EU SaaS relieves you of operations and spec maintenance.
- How is your user base developing? Growing strongly → compare usage-based models early against predictable Health IAM plans.
Frequently Asked Questions
Can I use Keycloak for a DiGA?
Technically yes – Keycloak supports OIDC. However, you have to build, certify, and continuously maintain the GesundheitsID federation and BSI TR-03161 compliance with the gematik specifications yourself. That is the actual effort, not the login itself.
Is Auth0 GDPR-compliant for health data?
Auth0 offers EU data hosting and can be operated GDPR-compliantly. However, many health teams also weigh the data sovereignty of a US parent company and the lack of native support for German health standards (gematik, GesundheitsID, TI).
What is the difference between a generic IAM and a Health IAM?
A generic IAM supports broad standards like OIDC and SAML. A Health IAM natively brings along the health-specific requirements: GesundheitsID federation, TI connection, TR-03161 compliance, and the associated proofs.
Is it worth switching from Keycloak or Auth0?
That depends on the scope. The closer you get to GesundheitsID, TI connection, or TR-03161 certification, the more the benefits of a specialized Health IAM outweigh – through less self-building, less maintenance, and a faster path to certification.
Are you currently evaluating your IAM for a DiGA? Talk to our team or get a free developer access and compare for yourself how azuma doa closes the GesundheitsID and TR-03161 gap of generic IAMs.