Skip to main content
Identity Authority
Category: Tokens & Sessions

Session Timeout

Also known as: User Session Timeout, Idle Session Timeout, Session Inactivity Timeout
Simply put

Session timeout is a security mechanism that ends an authenticated session after a set period, often automatically logging the user out. It is commonly triggered either by a period of inactivity or by reaching a maximum overall session length, at which point the user typically must sign in again.

Formal definition

A session timeout is a session management control that terminates an authenticated session based on a configured time limit, requiring reauthentication to establish a new session. NIST SP 800-63B describes two distinct types: an overall (absolute) timeout that caps the total duration of a session following authentication, and an idle (inactivity) timeout that ends a session after a period without activity on the client connection. Default and configurable values vary by platform (for example, AWS Systems Manager sessions default to 20 minutes of inactivity and are configurable between 1 and 60 minutes, and Microsoft Dynamics 365 Business Central uses a default SessionTimeout of 00:20:00). This control governs the lifetime of an already-authenticated session and is distinct from the initial authentication and authorization decisions; exact behavior depends on vendor and deployment configuration.

Why it matters

Session timeouts limit the window during which an authenticated session can be abused if a device is left unattended, a session token is stolen, or a user simply walks away from a workstation. Because the control governs the lifetime of an already-authenticated session, it addresses risks that the initial authentication decision cannot: even a strongly authenticated session becomes a liability if it persists indefinitely. By capping session duration, timeouts reduce the exposure created by unlocked or shared devices and by long-lived credentials.

NIST SP 800-63B describes two complementary controls that address different threats. An overall (absolute) timeout caps the total duration of a session following authentication, forcing reauthentication regardless of activity, which bounds how long a compromised or hijacked session can remain valid. An idle (inactivity) timeout ends a session after a period without activity, which addresses the abandoned-session scenario. Deploying only one leaves a gap: an inactivity timeout alone does nothing to bound an actively abused session, while an absolute timeout alone may leave an idle session open for its full configured lifetime.

Getting the value right is a balance between security and usability, and it depends heavily on context. Overly aggressive timeouts frustrate users and can drive risky workarounds, while overly permissive ones extend the attacker's window. Because defaults and configurable ranges vary by platform, organizations should set timeouts deliberately against their own risk tolerance rather than relying on vendor defaults.

Who it's relevant to

IAM Engineers and System Administrators
These practitioners configure timeout values, choosing between absolute and idle modes and setting durations within each platform's supported range. Because defaults such as AWS Systems Manager's 20-minute inactivity timeout (configurable from 1 to 60 minutes) and Dynamics 365 Business Central's 00:20:00 default vary by product, they must evaluate each system's options rather than assume uniform behavior.
Security Architects
Architects decide how session timeouts fit into a broader session management strategy, including whether to combine absolute and idle timeouts as described by NIST SP 800-63B to address both hijacked-session and abandoned-session risks. They weigh the security benefit of shorter sessions against usability impact for a given deployment's risk profile.
Compliance Officers and Auditors
Timeout settings are a common control referenced in security requirements, and auditors verify that configured values align with policy. NIST SP 800-63B's distinction between overall and idle timeouts provides a reference framework, though the exact required behavior depends on the applicable standard and deployment context.

Inside Session Timeout

Idle (Inactivity) Timeout
A limit that ends or invalidates a session after a defined period without user activity. It reduces exposure from unattended sessions, and its length is typically configurable per application or risk tier.
Absolute (Maximum) Session Lifetime
A hard upper bound on how long a session remains valid regardless of activity, after which re-authentication is required. This bounds the total window in which a hijacked session or stale authentication context can be used.
Session Identifier and Token Handling
The server-side session record or client-held token whose validity is governed by the timeout. Depending on the architecture, expiry may be enforced by invalidating a server-side session, by the expiration (exp) claim of a self-contained token such as a JWT, or by short-lived access tokens refreshed via a refresh token.
Re-authentication and Step-up Triggers
The behavior when a session expires, which typically requires the user to authenticate again. In some deployments a timeout can trigger step-up authentication rather than a full new login, depending on the sensitivity of the requested action.
Timeout Scope and Propagation
Whether a timeout applies to a single application, a federated SSO session at the identity provider, or downstream tokens. In federated setups (for example SAML 2.0 or OIDC), an IdP session and a relying party session may have independent timeouts, so expiry at one layer does not always terminate the others.

Common questions

Answers to the questions practitioners most commonly ask about Session Timeout.

Does a session timeout log the user out of every application they accessed through single sign-on?
Not necessarily. A session timeout typically applies to a specific session context, for example, an application session or an identity provider (IdP) session, and the two are distinct. In many SSO deployments, an application-level session can expire while the IdP session remains valid, meaning the user may be silently re-authenticated on their next request without entering credentials. Conversely, an IdP session timeout does not automatically terminate downstream application sessions unless single logout or back-channel session management is configured. The exact behavior depends on the federation profile and deployment configuration.
Is a session timeout the same thing as an access token or JWT expiring?
No, though they are related and often confused. Token expiration (for example, the exp claim in a JWT) governs how long a bearer credential is accepted at runtime by a resource or relying party. A session timeout typically governs the lifetime of a broader session state, which may span multiple tokens or token refreshes. Depending on configuration, a short-lived access token can expire and be refreshed repeatedly while a longer session remains active, or a session can be terminated independently of any individual token's validity. Treat token lifetime and session lifetime as separate controls that interact rather than as a single mechanism.
How do idle timeout and absolute timeout differ, and should both be configured?
An idle (inactivity) timeout ends a session after a period without user activity, while an absolute (maximum) timeout ends a session after a fixed duration regardless of activity. In most deployments both are configured together: the idle timeout limits exposure from unattended sessions, and the absolute timeout caps the total lifetime of any session even for an actively used one. Appropriate values depend on risk tolerance, the sensitivity of the protected resources, and applicable compliance requirements, so specific durations vary by context.
Where should session timeout be enforced, at the application, the identity provider, or both?
This depends on your architecture. In federated SSO environments, timeouts can be enforced at the application (relying party) session, the IdP session, and any intermediary such as an access gateway or reverse proxy. Enforcing at only one layer can leave gaps, for example, an application timeout that a still-valid IdP session silently overrides. Many deployments coordinate timeouts across layers, or rely on session management features of the federation profile, so that termination behavior is predictable. Confirm how your specific IdP, gateway, and applications interpret and propagate session state.
How does step-up authentication interact with session timeout?
Step-up authentication typically requires a stronger or more recent authentication event for higher-risk operations, and it can be tied to session freshness rather than full session expiration. In many implementations, a session may remain valid overall while a specific sensitive action requires re-authentication because the last authentication exceeded an allowed recency window (sometimes expressed via a max age parameter or an authentication timestamp claim). This lets a session persist for lower-risk activity while still enforcing tighter recency for privileged actions, depending on policy and configuration.
What should happen to refresh tokens and active tokens when a session times out?
Behavior depends on the deployment and token design. Self-contained tokens such as signed JWTs generally remain technically valid until their own expiration because they are validated without a server-side lookup, so a session timeout alone may not immediately invalidate an already-issued access token unless additional revocation or introspection is used. Refresh tokens can be revoked to prevent new access tokens from being issued after a session ends. Deployments that require immediate termination often combine short token lifetimes, token revocation or introspection, and coordinated session management, since a session timeout at one layer does not inherently revoke credentials at another.

Common misconceptions

Session timeout is an authorization control.
Session timeout governs the validity of an authenticated session over time, which is an authentication-lifecycle concern. It determines when a principal must re-establish who they are, not what that principal is permitted to do; authorization decisions are evaluated separately, often per request, by a PDP/PEP regardless of session age.
Setting a token's expiration is the same as terminating the session everywhere.
With self-contained tokens such as JWTs, expiry is typically checked by validating the exp claim, and the token generally remains usable until it expires unless additional revocation or introspection is in place. A server-side session invalidation and a client-held token's independent lifetime are distinct, and in federated deployments IdP and relying-party sessions can expire on different schedules.
A single timeout value fits all applications and users.
Appropriate timeout durations vary by risk, data sensitivity, and deployment context. Idle timeout and absolute lifetime serve different purposes and are usually configured independently, and shorter values improve security but can degrade usability, so the balance depends on configuration and threat model.

Best practices

Configure idle timeout and absolute maximum session lifetime as separate controls, setting shorter idle windows for higher-risk or more sensitive applications.
Where self-contained tokens are used, keep access token lifetimes short and pair them with refresh tokens or introspection/revocation so that expiry and revocation are enforced in a timely manner, since a signed token is not automatically revocable.
Clarify timeout scope in federated environments so that IdP session expiry and relying-party session expiry are coordinated per your intended behavior, rather than assuming one terminates the others.
Prefer step-up or re-authentication on timeout for sensitive actions rather than a full logout where usability matters, but require full re-authentication when the absolute session lifetime is reached.
Tune timeout durations to the risk tier and deployment context rather than applying a single global value, and document the rationale for compliance and audit purposes.
Ensure session and token expiry events are logged so that timeout-driven re-authentication and session termination are auditable.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide