Identity Model

The stable user identity Hawcx provides, how it maps across your applications, and why Hawcx is not your profile store

Hawcx is the authentication and identity layer your applications consume. It proves who a user is and hands your backend a stable identifier for that user. It is deliberately not a profile or directory store. Your applications remain the system of record for user data.

The Stable User ID

When a user authenticates, your backend receives a signed OIDC ID Token whose sub claim is the stable identifier for that user. This is the key you use to link your own records to Hawcx.

Store the sub

Most applications store sub as a unique-indexed column (for example users.hawcx_sub) and keep their own internal primary key alongside it. Your profile data is keyed on sub; Hawcx never holds that profile data. For standard (self-service) users the sub is stable across logins and even across email changes. One exception: for SCIM-provisioned identities the sub is derived from the email, so it can change if the directory changes the user's email — reconcile SCIM-sourced records on email change accordingly.

The token also carries email, email_verified, phone_number, auth_time, amr, and other claims. See the ID Token reference for the complete list.

One Identity Across Multiple Apps

Identity is scoped to a project. Within one project, a user is a single record with a single sub, and that sub is identical everywhere the identity is consumed:

Put every application that must recognize the same user in one Hawcx project.
Register each application as its own OAuth client (its own aud / Client ID) in that project.
Every app verifies tokens against the same project JWKS and sees the same sub for the same person.

This is what lets a suite of applications or portals present one consolidated login and recognize a returning user across all of them. See OIDC Application Login for the request flow and session behavior.

Separate projects do not share identity

The same person in two different projects is two independent records with two different sub values and no linkage. If your goal is one identity across several apps, they must live in one project with multiple OAuth clients, not one project per app.

How Identity Is Delivered

Identity reaches your application in exactly one way: the signed OIDC ID Token, redeemed by your backend at the token endpoint (a pull model). Hawcx does not push identity to your app through a webhook or a separate profile API. Everything your app knows about the user at login time comes from the verified token claims.

Why Hawcx Is Not Your Profile Store

Keeping profile data out of the authentication layer is a deliberate security posture, not a missing feature:

Smaller blast radius. A compromise of the auth vendor never exposes your subscriber data, because that data was never there.
You keep control of PII. Your profile data stays in your systems, which matters under data-residency regimes such as GDPR and regional requirements.
Clean separation of concerns. Hawcx proves identity; your application owns the profile keyed on that identity.

Concentrating identity proof and profile data in one external platform creates a larger single target. Separating them is the stronger posture, and it is the one Hawcx is built around.

Next Steps

OIDC Application Login: the request flow and multi-app consolidation
ID Token reference: the full claim set
Account Recovery: the identity is stable across device re-enrollment