Skip to main content
Identity Authority
Category: Tokens & Sessions

Session Cookie

Also known as: Non-persistent cookie, Temporary cookie, In-memory cookie
Simply put

A session cookie is a small, temporary data file that a website stores in a user's browser only for the duration of their visit. Unlike cookies that persist across visits, it is typically discarded when the browsing session ends, so it is often used to keep track of a user's activity in real time while they move through a site.

Formal definition

A session cookie is an HTTP cookie sent without a Max-Age or Expires attribute, causing the browser to treat it as non-persistent and delete it when the current session ends; note that the browser, not the server, defines when a session terminates, and behavior can vary by browser (for example, some restore prior sessions). In IAM contexts, a session cookie commonly carries or references a server-side session identifier used to maintain authenticated state after an initial authentication step, distinguishing it from persistent cookies and from token-based approaches. The cookie itself is a session-state transport mechanism and does not by itself perform authentication or authorization; its security depends on configuration such as Secure, HttpOnly, and SameSite attributes, which are out of scope for this base definition.

Why it matters

Session cookies are a foundational mechanism for maintaining authenticated state in web applications. After a user completes an initial authentication step, the application typically issues a session cookie that carries or references a server-side session identifier, allowing subsequent requests to be associated with the already-authenticated principal without re-prompting for credentials. This makes the session cookie a high-value target: whoever holds a valid session cookie can generally act as the authenticated user for the life of that session, which is why its handling and protection matter as much as the authentication event that preceded it.

Because a session cookie transports session state rather than performing authentication or authorization itself, its security depends heavily on configuration and on how the browser and server manage session lifetime. A subtle but important point for architects is that the browser, not the server, defines when a session ends, and behavior varies across browsers; some restore prior sessions on relaunch, which can extend the practical lifetime of a cookie the server intended to be short-lived. Misalignment between server-side session expectations and browser-side persistence can leave authenticated state available longer than intended.

Understanding session cookies also clarifies the design tradeoff between server-side session approaches and token-based approaches, a comparison teams routinely weigh when choosing how to maintain state after login. Neither is universally superior; the choice depends on deployment context, scalability needs, and how session invalidation, storage, and validation are handled.

Who it's relevant to

IAM Engineers
Engineers implementing web SSO and session management need to understand that a session cookie typically references server-side authenticated state established after an initial authentication step. They should account for the fact that the browser defines when a session ends, which affects how session invalidation and expiration are enforced in practice.
Security Architects
Architects choosing between server-side session approaches and token-based approaches should treat the session cookie as a state-transport decision, not an authentication mechanism. Because behavior varies by browser, including possible session restoration, architects should validate that intended session lifetimes hold across the browsers their users run.
System Administrators
Administrators operating applications that rely on session cookies should recognize that the cookie's protection depends on configuration such as Secure, HttpOnly, and SameSite attributes, and that a non-persistent cookie is one issued without Max-Age or Expires. Deployment behavior can differ across browsers, so verification in the target environment is warranted.
Compliance Officers
Officers reviewing cookie handling should note that session cookies are temporary and typically discarded when the browsing session ends, which distinguishes them from persistent cookies for purposes such as consent and data handling assessments. The exact lifetime, however, can depend on browser behavior rather than server intent alone.

Inside Session Cookie

Session Identifier
Typically an opaque, high-entropy value that references server-side session state rather than encoding it directly. The identifier itself usually carries no meaningful data and serves as a lookup key into a session store.
Cookie Attributes
Flags and directives that govern how the browser handles the cookie, including Secure (restricts transmission to HTTPS), HttpOnly (blocks JavaScript access), SameSite (constrains cross-site sending), Domain, Path, and expiration controls such as Max-Age or Expires.
Scope Controls (Domain and Path)
Attributes that determine which hosts and URL paths the cookie is sent to, bounding where the session is considered valid within an application's domain space.
Lifetime Controls
Directives distinguishing session cookies that expire when the browser session ends from persistent cookies with an explicit Expires or Max-Age. This governs how long the reference to the server-side session remains usable from the client.
Server-Side Session State (referenced, not contained)
In most deployments the authenticated context, principal identity, granted attributes, and authorization decisions, lives on the server and is merely referenced by the cookie. Self-contained variants may instead encode state in a signed token, which shifts trust considerations.

Common questions

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

Does a session cookie authenticate the user on every request?
No. A session cookie does not perform authentication; it maintains state after authentication has already occurred. The user is authenticated once (identification, then authentication), and the resulting session cookie is presented on subsequent requests as evidence of that existing session. Validating the cookie confirms the request belongs to an established session, but it is not the same as re-verifying the user's identity. Where higher assurance is needed, deployments typically layer step-up authentication on top of the existing session rather than relying on the cookie alone.
Is a session cookie the same as a token such as a JWT?
Not necessarily, and the two concepts operate at different layers. A session cookie is an HTTP transport mechanism for carrying a value to the browser and back, while a token describes the format and content of a credential. A session cookie may carry an opaque session identifier that references server-side state, or it may carry a self-contained token such as a signed JWT. The cookie is the container; the token, when present, is the payload. Treating every session cookie as a JWT, or assuming a JWT implies a cookie, conflates transport with credential format.
Should session cookies be set with Secure, HttpOnly, and SameSite attributes?
In most deployments, session cookies are set with the Secure attribute to restrict transmission to HTTPS, the HttpOnly attribute to prevent access from client-side scripts, and an appropriate SameSite value to limit cross-site sending. The exact SameSite setting depends on whether cross-site flows, such as certain federation redirects, are required; some SSO scenarios need SameSite=None with Secure, while stricter values reduce cross-site request forgery exposure. The correct combination depends on your application's cross-origin requirements and threat model.
How should session cookies be invalidated at logout?
Invalidation behavior depends on whether the cookie references server-side state or is self-contained. For an opaque session identifier tied to server-side state, logout typically destroys or expires the server-side session so the cookie value no longer resolves, in addition to instructing the browser to clear the cookie. For a self-contained token carried in the cookie, clearing the browser cookie alone may not revoke a still-valid token before its expiry, so many deployments add server-side revocation or short lifetimes. Clearing the cookie on the client and terminating the session on the server should generally be treated as separate steps.
What lifetime and rotation practices apply to session cookies?
Lifetime and rotation choices vary by risk tolerance and configuration. Many deployments use short-lived session cookies with idle and absolute timeouts to bound exposure if a cookie is captured. Rotating the session identifier after authentication, and again after privilege changes, is a common practice to reduce session fixation risk. The specific timeout values and rotation triggers depend on the sensitivity of the protected resources and applicable policy; there is no single value that fits every deployment.
How do session cookies relate to federated SSO sessions?
In federated SSO, session cookies typically exist at more than one layer, and they are distinct. The identity provider may maintain its own session cookie representing the authenticated user at the IdP, while each relying application maintains a separate local session cookie after it consumes an assertion or token. Ending one session does not automatically end the others unless a coordinated logout mechanism is in place. Because scope varies by profile and vendor, single logout behavior should be verified against the specific federation configuration in use.

Common misconceptions

A session cookie proves the user is authenticated on every request.
A session cookie is a bearer reference to a prior authentication event, not a fresh authentication. Anyone who obtains the cookie can typically present it, which is why possession of the cookie is treated as possession of the session. Re-authentication or step-up authentication is used when a higher assurance is needed for a specific action.
Marking a cookie Secure or signing its contents means the session data is encrypted and confidential.
Secure only restricts transmission to HTTPS, and signing (in self-contained variants) provides integrity and authenticity, not confidentiality. A signed token is not an encrypted token; readable claims remain readable unless the payload is separately encrypted.
Session cookies and OAuth/OIDC tokens are the same thing.
A session cookie typically maintains an application's local web session, whereas access tokens, ID tokens, and refresh tokens are protocol artifacts with distinct purposes and validation rules. They can coexist, an application may establish a session cookie after completing an OIDC flow, but they are not interchangeable.

Best practices

Set HttpOnly to prevent client-side script access and Secure to ensure the cookie is only transmitted over HTTPS, reducing exposure to theft.
Apply an appropriate SameSite value (Strict or Lax depending on cross-site requirements) to limit the cookie's use in cross-site request contexts, and constrain Domain and Path to the narrowest scope the application needs.
Prefer opaque, high-entropy session identifiers backed by server-side session state so that sessions can be revoked or invalidated centrally without relying solely on client-held data.
Regenerate the session identifier upon privilege changes such as login or step-up authentication to mitigate session fixation.
Enforce both idle and absolute session lifetimes, and provide server-side termination so that logout or administrative revocation actually invalidates the session rather than leaving the reference usable.
If self-contained or signed session tokens are used, validate signatures on every request and apply payload encryption where confidentiality of the contained data is required, since signing alone does not provide confidentiality.
Application Security Isn’t Optional Anymore.