Documentation Index
Fetch the complete documentation index at: https://docs.mgpass.net/llms.txt
Use this file to discover all available pages before exploring further.
Token Lifecycle
mgPass issues three types of tokens during authentication:| Token | Purpose | Default Lifetime | Configurable |
|---|---|---|---|
| Access Token | Authorize API requests | 1 hour | Per-app (access_token_ttl) |
| Refresh Token | Obtain new access tokens | 30 days | Per-app (refresh_token_ttl) |
| ID Token | Identity claims (name, email, etc.) | 1 hour | Same as access token |
Proactive Token Refresh
Do not wait for a 401 error to refresh tokens. Instead, schedule a refresh at 80% of the token’s lifetime:Refresh Token Rotation
mgPass enforces refresh token rotation for security. Every time you use a refresh token, mgPass returns a new one and invalidates the old:Replay Detection (Theft Protection)
If a previously-used refresh token is submitted (indicating potential token theft), mgPass takes aggressive action:- All refresh tokens for that user session are revoked
- All active sessions for that user are destroyed
- The user must re-authenticate everywhere
Automatic Refresh Interceptor
For web applications, wrap your HTTP client with an interceptor that handles token refresh automatically:Fallback to Silent Auth
If a refresh token is expired or revoked, fall back to silent authentication usingprompt=none:
The
prompt=none fallback works because mgPass may still have a valid session cookie even after your refresh token has expired. This is especially common with same-domain SSO where the session cookie was refreshed by another application.Token Storage
Where you store tokens matters for security:| Platform | Access Token | Refresh Token |
|---|---|---|
| Server-rendered web app | Server-side session | Server-side session or encrypted httpOnly cookie |
| SPA (browser) | Memory (JavaScript variable) | httpOnly secure cookie via BFF pattern |
| Mobile / Native | Secure enclave / Keychain | Secure enclave / Keychain |
Backend-for-Frontend (BFF) Pattern for SPAs
Since SPAs cannot securely store refresh tokens in the browser, use a lightweight backend proxy: The SPA only ever sees the access token (held in memory). The refresh token lives in an httpOnly cookie managed by your backend, invisible to client-side JavaScript.Configuration
Token lifetimes are configured per-application in the mgPass admin console or via the API:| Field | Default | Description |
|---|---|---|
access_token_ttl | 3600 (1 hour) | Access token lifetime in seconds |
refresh_token_ttl | 2592000 (30 days) | Refresh token lifetime in seconds |
Shorter access token TTLs are more secure (less time for a stolen token to be used) but increase the frequency of refresh requests. 1 hour is a good default for most applications.
Next Steps
- SSO Guide — understand how single sign-on works across domains
- OAuth Flows — the full token exchange flow
- Sessions & Tokens — deeper dive into session management

