Sessions & tokens
After a successful authentication, Fanzava issues tokens that the client uses for subsequent requests. This page covers how those tokens work, how sessions are managed, and how to revoke them.
Token model
Section titled “Token model”Fanzava uses a two-token model derived from OAuth 2.0 conventions:
| Token | Lifetime | Purpose |
|---|---|---|
| ID token | 1 hour | Identifies the user and carries authorisation claims; sent with every API request |
| Refresh token | 30 days (configurable) | Used to obtain a new ID token without re-authenticating |
The ID token is short-lived deliberately, so that revoked or stale credentials lose access within the hour. The refresh token provides continuity without forcing the user to log in every hour.
Token contents
Section titled “Token contents”The ID token is a signed JWT carrying:
sub— the user’s pseudonymised UUID (no email or PII in the token itself)hub_memberships— list of hubs the user belongs to, with role per hubgroup_memberships— group IDs the user belongs to, scoped by hubpermissions— derived permission set (computed from role + group membership)iat/exp— issued-at and expiry timestampsaud— the Fanzava API audience identifieriss— the issuing auth provider
The token is signed with RS256. Signing keys are rotated every 90 days, with a 7-day overlap window so in-flight tokens remain valid through key rotation.
Because the token carries authorisation claims, authorisation checks are done by reading the token rather than re-querying the database on every request. This keeps the API fast — no per-request database lookup for hub or role — and the short ID token lifetime means changes to a user’s role or membership take effect within an hour.
Session lifetime
Section titled “Session lifetime”A session is the period during which a user can refresh their ID token without re-authenticating. Default lifetime is 8 hours, after which the refresh token expires and the user must sign in again.
Hub admins on Enterprise plans can configure session lifetime from Admin → Settings → Security → Sessions:
- 1 hour to 30 days
- Optional “remember me” toggle for participants (extends to 30 days on opt-in)
- Optional idle re-authentication (force sign-in after N minutes of inactivity)
Revocation
Section titled “Revocation”Tokens can be revoked at any time:
- By the user — signing out from any device revokes that session
- By the user — “Sign out everywhere” revokes all sessions on all devices
- Automatically on password change — all sessions revoked
- Automatically on email change — all sessions revoked
- Automatically on MFA disablement — all sessions revoked
- By the hub admin — revoking a participant’s role triggers session revocation for that hub
- By Fanzava — for security incidents (compromised account suspected, abuse detected)
Revocation propagates within seconds via Fanzava’s session store. A revoked ID token, even if not yet expired, will be rejected on its next API request.
Concurrent sessions
Section titled “Concurrent sessions”Default behaviour permits multiple concurrent sessions per user (sign in from phone and laptop simultaneously). Hub admins on Enterprise plans can restrict concurrent sessions from Admin → Settings → Security → Sessions:
- Maximum N concurrent sessions per user (default unlimited)
- Single session enforcement (signing in elsewhere logs out the previous session)
Idle timeout and absolute timeout
Section titled “Idle timeout and absolute timeout”By default, an active browser session expires after 8 hours regardless of activity. Hub admins on Enterprise plans can configure:
- Idle timeout — force re-authentication after N minutes of no activity (default off; recommended 30 minutes for high-sensitivity hubs)
- Absolute timeout — force re-authentication after N hours regardless of activity (default 8 hours)
Re-authentication for sensitive operations
Section titled “Re-authentication for sensitive operations”Some operations require a fresh authentication regardless of session state:
- Changing email address
- Changing password
- Disabling MFA
- Adding or removing MFA factors
- Generating an API key
- Downloading participant data exports (Enterprise — configurable)
For these operations, the user re-enters their password (or completes a new SSO challenge) and, if MFA is enabled, completes an MFA challenge. The fresh authentication doesn’t extend the session; it confirms presence at the moment of action.