Sessions & refresh
A session is a refresh token plus the access tokens it mints. There are three shapes, chosen at login by what you send.
Web session
Log in with ?web=true. The refresh token is set as an HttpOnly cookie (not
in the response body), which is what you want for a browser. Default lifetime:
30 days.
Device (mobile) session
A mobile app declares a device at login by sending a device object. It gets a
longer, device-bound, sliding session and a stable device identity.
{
"password": "…",
"audience": "https://api.acme.com",
"device": { "name": "Ana's iPhone", "platform": "ios" }
}
- The response includes a server-issued
deviceId. Store it and resend it on the next login — that is how the same phone is recognised instead of piling up duplicate device rows. - The access token carries a
device_idclaim. - Default lifetime: 90 days, sliding — every refresh pushes the expiry to
now + TTL, so an active device stays signed in and an idle one lapses.
Users can see and revoke their own devices:
GET /api/users/me/devicesDELETE /api/users/me/devices/{deviceId}— logs that device out; other devices are untouched.
Plain (non-web, non-device) session
Log in with neither ?web=true nor a device object and the 30-day refresh
token is returned in the body. Useful for scripts and back-end integrations.
Per-application session length
Each application can override how long its refresh tokens live — separately for web and device — within platform bounds of 1 to 180 days. Leave it unset to inherit the platform default (web 30 / device 90). Set it when you register or manage the application; a regulated app can go shorter, a consumer mobile app longer.
Refreshing
POST /api/auth/refresh with the current refresh token returns a new access
token and a new refresh token — the old one is now dead. Always persist the
new refresh token. Replaying an old one is treated as theft and revokes the whole
session family. The SDKs handle rotation for you.