Sessions & tokens

Access tokens, refresh rotation, revocation, sign-out everywhere.

Two tokens, two jobs

	Access token	Refresh token
Lifetime	Short (default 60 minutes, configurable 5–1440)	Long (default 30 days, configurable 1–365)
Held in	Memory	Secure storage
Sent as	`X-Flares-User-Token` (or `Authorization: Bearer` to Functions)	Only in the request body of `/refresh` and `/signout`
Verified	Statelessly, by signature — and bound to one project	Against the sessions table, by hash

The access token binds issuer, subject, project and expiry. A token minted for project A verifies nowhere else — the signature is derived per project, so cross-project replay fails at the signature, not at a lookup.

Refresh rotation, and what replay costs an attacker

Refreshing issues a new refresh token and retires the one you used. Present a retired token and Flares concludes two parties hold this session — the copy was stolen — and revokes the entire family. The legitimate user signs in again; so must the attacker, who no longer can.

refresh(A) → B, A retired
refresh(A) again → the whole family is revoked; B stops working too

A session's horizon does not extend by refreshing: it lives at most refresh_ttl_days from sign-in.

Ending sessions

Action	Endpoint / place	Effect
Sign out	`POST /auth/signout`	Ends that one session's family. Unknown tokens succeed silently — sign-out is idempotent and reveals nothing.
Sign out everywhere	`POST /auth/signout-all` (with the access token)	Ends every session the user holds.
Revoke (admin)	Console, or `POST /auth/users/{user}/revoke-sessions`	Same, performed by you.
Disable the user	Console, or `PATCH …/users/{user}`	Revokes sessions and blocks new ones; their access token stops resolving.
Password reset completed	Automatic	Every session is revoked — a reset that leaves the thief signed in is theatre.

Viewing sessions

A user's detail page lists their active sessions with start, last use, expiry, address and client. Managing users →