Auth model

CAIL Health uses two separate identity providers for its two audiences. The two paths never mix: a token issued for one audience is not accepted on the other.

Patient clients (Firebase Auth)

Patient applications sign in anonymously through Firebase Auth and call the API with the resulting ID token.

• Sign-in is anonymous. No name, email, or other identifier is required.
• The token carries an anonymous user identifier (UID) and nothing else that could identify the patient.
• The API does not extract or store personally identifying information from the token, and patient-facing endpoints are designed to operate without any such information.

A typical client flow:

1. The application uses the Firebase SDK to obtain an anonymous ID token.
2. Each API request includes the token in the Authorization header as Bearer <token>.
3. The API validates the token and resolves the active jurisdiction for the session.

Commissioner clients (Auth0)

Commissioner applications sign in through Auth0 and call the API with the resulting ID token.

• The token carries the user’s identifier and the organization the user belongs to.
• The organization governs what the user can see and do.

A typical client flow:

1. The user signs in through the commissioner application, which performs an Auth0 login.
2. Each API request includes the resulting token in the Authorization header as Bearer <token>.
3. The API validates the token, derives the organization, and enforces the user’s permissions within it.

Endpoint scoping

Each endpoint is scoped to exactly one of the two audiences. Patient endpoints reject commissioner tokens and vice versa. The required token type is documented per endpoint.