Auth
Sign your app's users in and carry their identity through every request.
Your app has its own users, separate from your console account. They sign in against your app and receive tokens scoped to it.
Access and refresh tokens
Signing in returns a short-lived access token (15 minutes) and a longer-lived refresh token. Send the access token as a bearer token:
Authorization: Bearer <access token>When it expires, exchange the refresh token at POST /{appUid}/auth/token for a new pair.
Refresh tokens are single-use: store the new pair every time, and make sure only one refresh
runs at once. Presenting a spent refresh token ends the session. See
Sessions & token refresh for the full client strategy.
The token carries the decision
A token states who the principal is and — for users belonging to several organizations — which organization is active. Both are established at sign-in or refresh, and neither can be changed by a query parameter on an individual request.
Why org context lives in the token
If the active organization could be switched per request, any request could claim any organization. Establishing it at sign-in makes it explicit, auditable, and consistent with the policies evaluated against it.
To switch organizations, refresh with the target — the server verifies membership before issuing tokens for it.
Many doors, one session
Password, magic link, email code, Google, GitHub — every method ends at the same token issuance and returns the same payload. Code that consumes a session never needs to know how the user signed in. See Sign-in methods.