Sessions, Cookies and Tokens

TL;DR: A server-side session uses an opaque identifier to retrieve current state. A bearer credential may be opaque or structured; possession lets a caller attempt the operations that its scope and the service policy permit. Protect browser cookies, enforce expiry on the server, and test revocation at every accepting service. Signed tokens permit local validation, but local validation alone does not establish current authorization.

The problem after login

HTTP is stateless. Once a user has authenticated, every later request needs to carry proof of who they are. There are two broad designs, and most systems mix them.

Server-side sessions

The server creates a session record (user ID, creation time, expiry, maybe roles) and stores it in memory, a database or a cache. The client gets a long random identifier, usually in a cookie. On each request the server looks the identifier up.

• Theft: whoever steals the identifier can use the session until it ends.
• Revocation: invalidate the authoritative record, then account for replicas, cached positive decisions and in-flight requests. Revocation latency depends on those paths.
• Cost: a lookup per request, and shared session storage for multiple servers.

Two classic bugs: session fixation, where the server keeps the same identifier from before login so an attacker who planted it gains access; fix it by issuing a new identifier at login and privilege changes. And predictable identifiers, fixed by using a cryptographic random generator with at least 128 bits.

Entropy and lifetime are separate requirements

Use a cryptographically secure random generator for opaque session identifiers. Predictable timestamps or counters do not contribute secret entropy merely because they make an identifier long. For this site's examples, choose at least 128 random bits; follow the chosen framework's documented session mechanism rather than designing a new token format.

The OWASP session management guidance distinguishes these controls. Select timeouts for the application's risk and workflow, enforce them server-side, and document the residual window introduced by caches. Browser cookie expiry is not a substitute for server expiry.

Bearer tokens

Bearer describes how a credential is used, not its serialization. An opaque access token may require an authorization-server lookup. A signed JWT exposes its claims to its holder and can be checked locally; an encrypted JWT has different confidentiality properties. OAuth does not require JWT access tokens.

A stolen bearer credential may be usable until expiration or effective withdrawal, subject to audience, scope and other enforced policy. Local signature verification cannot detect a role change or logout by itself. Introspection, current authorization checks, revocation state or short lifetimes can bound that gap, with different availability and consistency costs.

Refresh-token revocation prevents future issuance through that grant once enforced; it does not automatically recall access tokens already issued. Refresh rotation also needs reuse handling and a deliberate policy for concurrent legitimate refreshes. Keep token values out of logs.

Cookies: the attributes that matter

Cookies are sent automatically by the browser, which is both convenient and the source of their risks.

For browser applications, an HttpOnly, Secure, SameSite session cookie is usually safer than a token in JavaScript-accessible storage.

Cookie policy must survive browser differences

Set attributes explicitly. Prefix enforcement and partitioned-cookie support depend on the browser, so verify the supported client set rather than assuming a name alone establishes the policy. The browser cookie reference documents the attributes and their conditions. A __Host- cookie constrains domain and path settings in supporting browsers; it does not stop script already executing in the application from invoking authenticated actions.

Keep the server's session lifetime authoritative. A browser may retain, restore or discard cookies independently of that policy. Logout must invalidate server authority as well as clearing the browser cookie.

Where tokens live in a browser app

For single-page applications, the IETF's best current practice for browser-based OAuth clients, RFC 10017 (August 2026), recommends a backend-for-frontend (BFF): a small server-side component that is the confidential OAuth client, keeps access and refresh tokens on the server, and gives the browser only an HttpOnly, __Host- session cookie. The browser calls the BFF, which calls the APIs. OAuth tokens stay out of page JavaScript in this design. Active malicious script can still invoke allowed BFF operations through the browser session, so the BFF needs CSRF protection, constrained proxy destinations and resource authorization. Where a BFF is not possible, a token-mediating backend that hands short-lived access tokens to the page is the fallback, ideally bound to a non-extractable key with DPoP; storing long-lived tokens in localStorage is the pattern to avoid.

Constrain use of a copied token

Bearer tokens have a structural weakness: possession is enough. Two standards can require possession of an additional key. A copied token alone then fails when the resource server correctly validates the binding and proof:

• DPoP (RFC 9449): the client proves possession of a private key with a signed header on each request.
• Mutual TLS-bound tokens (RFC 8705): the token is bound to the client's TLS certificate.

These controls do not protect against every use of a compromised client runtime. If an unauthorized process can invoke the key operation, non-exportability alone does not prevent misuse. Never use logs as token storage.

Run a session lifecycle acceptance fixture

The following fictional policy permits fifteen minutes of inactivity and eight hours of total session age. Times are integer seconds on an exercise clock. The function consumes a fresh authoritative record; it does not parse cookies, authenticate users or demonstrate a distributed cache. A missing record fails closed for this operation.

from dataclasses import dataclass, replace

@dataclass(frozen=True)
class Session:
    created: int
    last_seen: int
    revoked: bool = False

def decision(session, now):
    if session is None or session.revoked:
        return "deny: withdrawn"
    if not session.created <= session.last_seen <= now:
        return "deny: clock or record"
    if now - session.created >= 8 * 3600:
        return "deny: absolute expiry"
    if now - session.last_seen >= 15 * 60:
        return "deny: idle expiry"
    return "allow"

active = Session(100, 1000)
print(decision(active, 1100))  # => allow
print(decision(replace(active, revoked=True), 1100))  # => deny: withdrawn
print(decision(active, 1900))  # => deny: idle expiry
print(decision(Session(100, 28899), 28900))  # => deny: absolute expiry
print(decision(None, 1100))  # => deny: withdrawn

After an allowed request, update activity according to the documented policy. Batching activity writes changes the effective idle behavior. Define atomicity for concurrent logout and refresh so a stale writer cannot recreate a withdrawn session. At a sensitive state change, decide whether permission must be checked again at commit; a request admitted before logout may otherwise finish afterward.

Now keep a copy of active in a resource cache and mark only the authoritative record revoked. The cached copy still returns allow. That is the acceptance test your distributed design must address. Choose a bounded cache lifetime, an authenticated invalidation mechanism, or an authoritative check for the sensitive operation. State how an unavailable session store affects the operation rather than silently permitting indefinitely stale decisions.

Misconceptions interviewers listen for

• "HttpOnly stops XSS." It stops script reading the cookie; injected script can still act as the user in the page.
• "SameSite replaces CSRF tokens." It is defence in depth: browser defaults differ, the two-minute POST exception exists, and subdomains are same-site.
• "A JWT in localStorage is stateless and therefore safer." Any script in the page can read and export it.
• "Logging out deletes the cookie." The server must invalidate the session, or a copied cookie keeps working.
• "A long session ID is secure." Only random bits count; fixed or predictable parts do not.

How this shows up in interviews

"Sessions or JWTs?" is a common design question, and "it depends" scores only if you name what it depends on: revocation needs, number of services verifying, browser versus server clients, and the theft model. Strong answers mention cookie attributes by name, the localStorage-plus-XSS problem, refresh token rotation, and sender-constrained tokens for high-risk clients such as agents.

Say it in 30 seconds: "A session is continuing authority. I protect its identifier, rotate it at authentication, enforce idle and absolute expiry on the server, and measure withdrawal at accepting services. JWT is a format, bearer is a usage model, and a valid signature is not evidence that permission is still current."