Session management is the process of maintaining a user’s state across application requests, from starting a session to renewing, expiring or ending access.

After a customer signs in, the application needs a way to recognize subsequent requests without asking for credentials on every page. A session connects those requests to the authenticated account. Its security matters for the entire visit, including actions taken long after login.

How session management works

A common browser implementation gives the customer an unpredictable session identifier in a cookie. The application uses that identifier to look up session state on the server. Other designs carry protected session information on the client, which changes how the application handles revocation and updates.

The application should replace the session identifier after authentication or a privilege change. This helps prevent session fixation, where an attacker tries to make a victim use an identifier the attacker already knows. Access checks still apply to each protected request.

Cookies need appropriate protection. Secure restricts their transmission to HTTPS, while HttpOnly prevents ordinary page scripts from reading them. SameSite limits cross-site cookie delivery. These settings address different risks and do not replace protection against cross-site scripting or forged requests.

When should a session end?

An idle timeout ends a session after a period without qualifying activity. An absolute timeout sets a maximum duration even if the customer remains active. The application must enforce both on the server; a browser countdown alone cannot withdraw access.

Consider a retail customer browsing products before changing a saved payment method. Keeping the browsing session open can be reasonable, while the payment change may require fresh authentication. That additional check should reflect the sensitivity of the action and any change in risk.

Logout should invalidate the relevant session state as well as clear the browser’s cookie. For a design using self-contained session tokens, immediate invalidation needs an explicit mechanism, such as a server-side revocation check. Deleting a local cookie does not invalidate a copy an attacker already holds.

Application sessions and identity-provider sessions

An application session can have a different lifetime from the session at its identity provider. Signing out locally may leave the identity-provider session available to sign the customer back in. Similarly, OAuth access and refresh tokens have their own purposes and lifecycles.

Teams should define what “sign out” and “sign out everywhere” mean across these components. A customer reporting a stolen device needs a way to remove that device’s access, with confirmation of which sessions were ended.

Frequently asked questions

Is a session the same as an access token?

No. A session maintains application state across requests. An access token authorizes access to a protected resource. An application may use both, with different expiration and revocation rules.

What is the difference between idle and absolute timeout?

Idle timeout limits inactivity. Absolute timeout limits total session duration regardless of activity. Both need server-side enforcement.

Does closing the browser always end a session?

No. Persistent cookies, browser restoration and server-side session state can allow access to continue. Applications should rely on explicit expiration and logout controls.

Related: Session Hijacking · Continuous Authentication · Step-Up Authentication · Account Takeover (ATO) · Single Sign-On (SSO) · Risk-Based Authentication