Tokens and revocation
auth4.dev issues short-lived signed tokens and keeps long-lived credentials out of reach of page scripts. This page explains what each token is for, where it lives and how quickly revocation takes effect.
Kinds of token
| Token | Purpose | Lifetime |
|---|---|---|
| Access token | Sent to your API as Authorization: Bearer …. RS256 JWT, audience is the client ID. | 5 minutes |
| ID token | Proves to the client who signed in. Validated by the browser SDK. Never send it to an API: servers reject it. | 5 minutes |
| Refresh token | Gets new access tokens without signing in again. Native games only, and only whenoffline_access was granted. | 7 days idle, 30 days absolute |
| Authorization code | Exchanged once by the browser SDK, with the PKCE verifier. | 60 seconds |
| Hosted-login browser session | An HttpOnly cookie on the auth origin. Used for device approval. Never visible to your page's scripts. | 12 hours idle, 7 days absolute |
Where tokens are kept
- Browser SDK: access and ID tokens stay in JavaScript memory and are never written to
localStorage,sessionStorageor cookies. Only the short-lived state, nonce and PKCE verifier are written tosessionStoragewhile a sign-in is in progress. Browser apps get no refresh token. - Unity SDK: tokens stay in memory unless you supply a secure storage adapter. Then only the refresh token, user ID and guest flag are stored.
- Your server: verifies access tokens and doesn't need to store them. Don't log tokens.
- Developer console: console tokens stay on the console's own server. The console page never sees them.
Refresh rotation
Every successful refresh returns a new refresh token and retires the old one. If a retired refresh token is used again, auth4.dev treats it as stolen and revokes the whole token family and its session, including the newest token. The Unity SDK sends only one refresh at a time, so normal parallel requests never trigger this.
Refresh is also refused, and the family revoked, when the player, application or project is disabled.
Revocation limits
You can end access in several ways:
- The player signs out (the SDKs revoke their token).
- An owner revokes a session, or all of a player's sessions, in the console.
- An owner disables a player or an application, or requests deletion.
- Refresh-token reuse is detected.
Each of these takes effect immediately for refresh, for the UserInfo endpoint and for new sign-ins. Access tokens already issued are signed, self-contained credentials, so:
Revoking a token that is unknown, expired or already revoked succeeds silently, so sign-out is safe to repeat.
Handling rules
- Send tokens only over HTTPS, and only to your own API and the auth origin.
- Never put tokens in URLs, logs, analytics events or crash reports.
- Verify access tokens on the server with a configured issuer and audience. Never trust claims you decoded without verifying.
- Use the access token, not the ID token, as an API credential.
- Key your data on
sub, never on the email address.