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.

Clinical Complexity and Seamless Patient Journeys

There is a second, often underestimated area where generic IAMs struggle: the organizational reality in healthcare. It is rarely flat. A manufacturer operates several DiGAs, a clinic group is divided into individual hospitals, specialized departments, and treatment teams – and a patient moves across provider boundaries: from the DiGA to the patient portal to the video consultation and follow-up care. This applies not only to the patient journey, but also to healthcare providers (doctors, nurses, ...). A digital journey in healthcare almost never ends in a single app.

While generic IAMs offer a form of multi-tenancy (Keycloak via Realms, Auth0 via Organizations), these boundaries are isolated by design. Mapping deep hierarchies and a shared identity across multiple tenants quickly leads to custom development, duplicated identities, or renewed onboarding at every step – friction that directly impacts activation and retention in the patient journey.

A Health IAM like azuma doa is built for exactly this complexity:

• Multi-Tenancy & Sub-Tenants: The real structure can be mapped 1:1 – a parent tenant (manufacturer or clinic group) with sub-tenants for individual products, hospitals, or departments. Each sub-tenant is isolated in terms of data and independently configurable, but centrally manageable.
• Multi-Hierarchy – one ID for multiple tenants: A once-verified patient identity (including GesundheitsID linkage) can be valid across multiple tenants. The patient carries their identity through the entire journey without re-registering or verifying at each product – while data isolation and consents are maintained per tenant.

The result is a seamless, low-friction patient journey and an architecture that grows with the organization, instead of being rebuilt with every new product or location.

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.
• Do you operate multiple products/locations or cross-provider patient journeys? Yes → Multi-tenancy with sub-tenants and a cross-tenant identity saves custom development and reduces friction in the journey.

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.

Does a Health IAM support multiple tenants and sub-tenants?

Yes. An IAM designed for healthcare maps complex organizational structures via multi-tenancy with sub-tenants – such as a manufacturer with multiple DiGAs or a clinic group with individual hospitals and departments. Each sub-tenant remains isolated in terms of data but can be managed centrally. While generic IAMs can separate tenants, they struggle with deep hierarchies.

Can a patient identity be used across multiple tenants?

Yes, via a multi-hierarchy: A once-verified, GesundheitsID-linked Patient-ID can be valid in multiple tenants. Thus, the patient carries their identity through a cross-provider journey – from the DiGA to the patient portal to follow-up care – without re-registration, while data isolation and consents per tenant are maintained.

---

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.