Identity

Authentication

Trestle keeps dashboard administrators, application users and machine identities separate so one credential cannot silently acquire another audience’s authority.

Application-user flow

  1. Register or sign in through the application authentication API.
  2. Receive a rotating refresh credential and short-lived access token.
  3. Send the access token as a bearer credential to collection, file and realtime APIs.
  4. When access expires, exchange the current refresh token once and persist its replacement atomically.
  5. On logout, revoke the refresh session and discard local credentials.
curl -X POST "$TRESTLE_URL/api/v1/auth/login" \
  -H "Content-Type: application/json" \
  --data '{"email":"nick@example.com","password":"correct horse battery staple"}'

Administrator flow

The embedded dashboard uses a server-side cookie session, CSRF token and origin checks. Do not reuse that cookie from an application client or automation script. Use a personal token for administrator-owned automation.

Machine flow

Create a scoped service account for each deployed workload. Store the copy-once secret in that workload’s secret manager and send it only over HTTPS.

Recovery boundary

Outbound email verification and password recovery are not yet implemented. Do not present a recovery UI that Trestle cannot complete.

Dogfood path

The CP21 incident desk keeps administrator sessions out of the application and uses short-lived application-user access tokens for every browser request. See the complete authentication flow.