Session lifetime is usually inherited from a framework default and never revisited until a customer's security team asks what it is. At that point somebody reads the configuration, discovers it is thirty days, and a conversation begins that would have been much shorter if a number had been chosen on purpose.
There is no correct value. There are three separate values, they answer different questions, and most products only configure one of them.
Three clocks, not one
The idle timeout ends a session after a period with no activity, and it is the one that protects an unattended screen. The absolute lifetime ends it regardless of activity, and it is the one that bounds a stolen session token: without it, an attacker with a live session keeps it forever by making a request every few minutes. The credential lifetime is how long the access token itself is valid, which governs how quickly a revocation takes effect.
Products that set only the third have an unbounded session with a short token, which sounds secure and is not. Products that set only the first sign people out during lunch and still cannot answer how long a compromise lasts.
- Idle timeout: protects the unattended device, felt by every user
- Absolute lifetime: bounds a stolen session, felt once per period
- Token lifetime: bounds revocation latency, invisible when refresh works
- Each is configurable per organisation, because customers will ask
A short token on an unbounded session is a comfortable arrangement that answers none of the questions people ask about it.
Let the action decide, not just the clock
A single global lifetime forces the whole product to the strictness of its most sensitive operation, which is why people end up choosing a lax value and hoping. The alternative is to keep an ordinary session comfortable and require re-authentication at the points that matter: changing a password, adding a second factor, exporting data, issuing an API key, changing where money goes.
Step-up re-authentication records a fresh timestamp on the session, and the sensitive operation requires that timestamp to be recent — measured in minutes. Most people never see it. The ones who do are about to do something they would want a prompt for.
Make the numbers visible and revocable
Enterprise customers frequently have a stated policy, and the ones who do will want your values to match it. Making idle and absolute lifetimes configurable per organisation is a small piece of work that turns a questionnaire row from an explanation into a yes, and it means their strict policy does not have to become everybody's.
Whatever the numbers, revocation has to be able to beat them. An administrator removing somebody expects access to end now, not at the next token expiry, which means sessions must be enumerable and killable by user and by organisation. Show people their own active sessions with device and location, and give them the same button.
- Per-organisation idle and absolute limits, with a sane default
- Re-authentication window for sensitive actions, measured in minutes
- Sessions listed and revocable by the user and by an administrator
- Password change and second-factor change end other sessions by default
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.