Identity as the Foundation: Auth0 and Protecting Health Data

A padlock as a symbol of identity protection Photo: EU2017EE Estonian Presidency · Wikimedia Commons (BY 2.0), via Openverse

Before you store even a single blood glucose reading or step count, you have to answer an uncomfortable question: who is actually allowed to see this data? For an ordinary app, that's a chore. For a health platform, it's the question everything hinges on. If identity isn't watertight, nothing else matters.

That's why the first layer we built at Xircuit wasn't a nice interface or a clever feature, but the foundation underneath it all — identity. This week I describe why we take it as seriously as almost nothing else in the system, and what decisions follow from that.

Why Health Data Is Different

The GDPR recognizes a handful of data types that it treats specially. Health data is one of them: under Article 9, it's a special category of personal data, alongside things like ethnic origin or religious belief. The legislature deliberately singled it out, because misuse here can't be undone. A leaked password can be changed. The information that someone has a chronic illness can never be taken back out of the world.

For us, that means a clear order of priority: protecting this data doesn't start at the database or at encryption, but at identity. If I can't say with high confidence who's actually signed in right now, the best encryption at rest won't help me much. The whole chain hangs on its first link, and the first link is sign-in.

This view has shaped our architectural decisions from the very beginning. For us, identity isn't one module among many, but the layer everything else builds on.

Why We Don't Store Passwords Ourselves

Perhaps the most important decision was not to build identity ourselves. It's tempting to set up your own user table with hashed passwords — it looks like little effort. In reality, you're taking on a responsibility you can barely carry: password hashing to current standards, brute-force protection, recovery flows that don't themselves become an attack vector, and ongoing maintenance against new attack patterns.

Instead, we chose Auth0, a company owned by Okta. Auth0 handles login, multi-factor authentication, social login, and account recovery. The crucial point here: Xircuit itself never stores a password. There's no column in our database that would hold a password hash. That means we can't suffer an entire class of incidents in the first place — you can't lose what you never possessed.

Multi-factor authentication isn't some optional extra buried deep in the settings. For a platform tied to health data, a second factor is the obvious baseline, and Auth0 gives it to us without us having to maintain the underlying cryptography ourselves.

Bringing Together Roles and Organizations

Auth0 knows who someone is. But it doesn't know what that person is allowed to do in Xircuit — and that's by design. Authorization logic belongs to the application, not the identity provider. So we bring two worlds together: identity from Auth0, and the role and organization structure from our own database.

One detail that became important early on: a user with us isn't tied to exactly one organization. The same person can be a member of multiple organizations — for example, a patient in one and a caregiver in another. The identity stays the same; the role depends on context. So at login, we establish not just who someone is, but which organization they're currently acting in and with what rights.

A fingerprint on a scanner Photo: Sanskritibharti1398 · Wikimedia Commons (BY-SA 4.0), via Openverse

Technically, that means the stable identifier from Auth0 serves as the anchor to which we attach our own membership and role records. Auth0 remains the source of truth for "who," our database the source of truth for "allowed to do what, and where." This separation sounds like a minor detail, but it keeps responsibilities clean: if a role changes, we don't touch Auth0; if someone changes their password, we don't touch our database.

Testability Without Back Doors

An identity system that can't be tested automatically is a risk in itself — because then you either don't test it at all, or you test it by hand, and both eventually lead to mistakes. At the same time, authentication is exactly the place where a convenient testing shortcut can turn into the most dangerous back door in the whole system.

We solve this with a clearly scoped ROPC test client that lets our end-to-end tests go through a real sign-in flow without remote-controlling the UI. That gives us reliable tests across the full auth path. But the important part is the boundary: this test authentication, and any kind of production back door, is hard-disabled in production. The test path exists only where it's supposed to exist, and in live operation it's simply not there — not disabled via a configuration setting that someone could accidentally flip, but fundamentally unreachable.

We take this distinction between "off" and "not present" seriously on purpose for security-relevant paths. A switch that can be flipped will eventually get flipped.

Diagnostics Without Revealing PII

Sign-in problems are one of the most common support requests of all, and they're notoriously hard to trace, because they span multiple systems — browser, Auth0, our API, our database. Anyone who's ever had to debug an "I can't get in" without usable logs knows how frustrating that is.

That's why we deliberately log what happens at every auth boundary: which step someone reaches, what the transition returns, where a sign-in breaks off. This boundary logging makes sign-in problems diagnosable instead of a guessing game. The crucial rule here is a strict no-go zone: we never log a password, and never personal data. We log the flow, not the content. You can see that a factor failed, but not which value was entered; you can see that an organization couldn't be resolved, but never real names.

That's a balancing act, and we treat it as one. Too little logging, and you're blind when it really matters. Too much, and the logs themselves become the data leak you were trying to prevent in the first place. For us, the line runs exactly where diagnostics would turn into an inference about a specific person.

What the Foundation Carries

If I had to sum up this week in one point: at Xircuit, identity isn't a feature, it's the prerequisite for all features. Auth0 takes the riskiest cryptography off our hands, the separation between identity and roles keeps responsibilities clean, the test path exists without production risk, and boundary logging makes the whole thing maintainable without endangering the data we're trying to protect.

None of this is particularly spectacular, and that's exactly the point. A good foundation doesn't draw attention to itself. It just holds everything up.