§03 Security & Privacy

Session Timeout Best Practice: How Long Should a Session Last?

Security & Privacy

Web applications tend to use a defining function or routine called a session to keep a user logged in until:

their session times out
they explicitly log out, or
an attacker captures the session token.

Fixed or copy-and-paste session timeouts are all too common in web applications, and they cause:

incidents when sessions outlast a user's actual session, such as when a logged-in device is lost or stolen, or
denial-of-service incidents when critical application sessions expiring within minutes of no activity.

Copying session-lasting configurations from a vendor or another application is extremely risky. Instead:

each session should be configured to fit the risk inherent in the application, in particular:
the confidentiality of the data accessed
the potential damage that can be done inside the application
the duration of an attacker's layer-of-attack window
each session should be configured based on the workflows of the actual users, and
each session should also obey the controls on refresh tokens and reauthentication.

Your goal in managing session lifetimes is to:

let the user do meaningful work, and
capture activity or reprompt reauthentication in a short time after key attack points:
for example, after a logout
or after a significant account change.

Your Timer Is Running: The Need for Absolute and Idle Session Lifetimes

A session timeout can catch an attacker in what might be called the window of attack opportunities - and the slowness of actual make-a-break access.

Absolute Timeouts Limit User Access

Security guidance recommends schemes where:

A session simply expires and requires reauthentication.
This shouldn't be cut short by an idle timeout.

With absolute timeouts, if your session becomes exposed:

after you've been logged in, or
after an attacker has stolen your session token,

then it will STAY usable, even if there is no user activity.

Attacker Window

The time between when the attacker starts an exploit and when they can achieve an attack - in this case, when they can examine, interfere with, or exfiltrate application data.

The OWASP Session Management Cheat Sheet advises:

Absolute timeout values should be set based on the type and criticality of the web application and the data the web application accesses.
For low-risk applications, this timeout can be as long as dozens of hours.
For example, the bulk of the timeout can run for a full day of office work.

Making You Chase Them Down

On the other hand, very short timeouts:

without exception - force regular re-authentication
risk destroying a legitimate user session

So in both cases, you need to catch an attacker inside the application, but you also need to respect the user workflow.

The WorkOS blog, describing OWASP advice, recommends:

Absolute maximum session durations between 4 and 8 hours.

Explicit Logouts Must Invalidate:

Application's that require explicit logout in browsers cannot control what the browser does, but should still:

Invalidate the corresponding session record, and
Clear the session cookie from the user's browser or storage.

Explicit timeout and logout processes invoke the principle known as the "least privilege." This principle limits access:

In this case, it implies that:
the session lasts no longer than it needs to or should, and

That the session is explicitly terminated as soon as the user is done.

What Do the Standards Say?

OWASP advises:

All sessions should have timeouts, but
Both idle and absolute timeout need to be adjusted based on risk, workflow, and token-lifetime settings.

NIST's B.6 Session Management guidance includes:

A requirement to "establish a session expiration time.. determined by the specific Authentication Policy Application."

Across the board, credentials should last no longer than:

the amount users can reasonably expect to use an application without a break,
the amount of access a user should have after a login, and
the refresh-token validity, which prohibits session-expiration. Validity periods for refresh tokens were originally established in the OAuth 2.0 framework to define limits for the maximum time scope during which a refresh token can be used.

People sometimes copy other sessions' Expires parameters, aimlessly worrying about security.

For session time limits related to refresh tokens, refresh tokens should be treated as single-use, with each use yielding a refreshed set of refresh tokens. The Calendly Developer Guide - Refresh token rotation guide:

Recommends issuing a new access and session token every time a refresh token is consumed, and
Immediately invalidating the refresh token.

Exploitation Techniques:

Thieving or violating the token can give an attacker access if either idle or absolute timeout is missing or exceedingly long.

Explicit logout remediates attacks that steal:

Memory caches, or
Network traffic to leak authentication tokens.

All: idle timeouts, explicit logouts, and refresh-token rotation complement effective principles in this case: "Limit subject privileges," "Ensure the ability for accountability," and ""

Refresh tokens have a tendency to be ideal for exploitation and are frequently cached to browser storage.

Choosing a Number: Attack Window, Revocation, and Workflow

Understanding attackers and session lengths is important, you also must understand work flows. If a user must unlock a machine or re-authenticate often, it'll:

Degrade User Experience, and
Force full attention to use a machine, phone, or browser.

WorkOS warns:

Absolute session durations should not be set too long, especially in financial or healthcare applications.

For highly sensitive environments, hotline checking or similar may make shorter expiration times acceptable.

Crucially, absolute limits are:

Necessary for tokens not instantiated, or
Active for long durations

The Calendly Developer Guide advises this combination:

8 hours, plus
15 minutes of no user activity,
For a maximum session length of 8 hours and 15 minutes

But you need to consider native features, maintainability, customer engagement, the experience when an employee needs help or when an employee leaves.

Whatever lifetime you choose, it must be shorter than the attacked window, longer than the refresh period, and assured by server-side session invalidation.

Going forward, this knowledge should help you from deciding session lengths without context.