Auth · Identities
The account itself — its name, photo, passphrase, passkey, email, claims, connections and sessions.
The account, and everything hanging off it. An identity carries a kind, an id, a display name, and
whichever of username, email and phone it was registered with — plus a photo, a passphrase, a passkey, claims,
provider connections and its live sessions, each with a route of its own.
Guards
Most of this surface is session-guarded and enforced by the handler against the identity in the path. Three parts are stricter:
- Own identity — passphrase, passkey and email refuse any session that is not that identity, an admin's included. Changing the address a recovery mail goes to is not an administrative act.
- Admin — claims and the notification routes, which write into every token the account is issued or send mail on its behalf.
POST /api/auth/identity/:id/emailis the exception inside the exception: assigning an address without proving it is admin-only.
Fields have routes
POST /api/auth/identity/:id changes several fields at once. Each field also has its own route —
…/name, …/photo, …/passphrase — which is what a settings screen wants, since
it can then save one control without sending the rest of the form.
Claims
Claims ride inside the identity token, so anything written there reaches every request the account makes. They are
also what GET /api/auth watches: a token minted before a claim changed is silently refreshed rather
than left stale.