> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.cail.health/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.cail.health/_mcp/server.

# 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.