Prerequisites

The Underlying Problem

HTTP is stateless. Each request arrives independently, carrying no inherent memory of previous requests. Once a user authenticates, the system needs some mechanism to recognize them on every subsequent request without asking for credentials again.

Two dominant approaches exist. The server can remember the session and give the client a reference to it, or the server can hand the client a signed statement that it verifies on each request.

Server-Side Sessions

In the session model, the server creates a record after successful authentication and returns only an unguessable identifier to the client, usually in a cookie. The authoritative state stays on the server.

CREATE TABLE user_sessions (
    session_id       VARCHAR(128) PRIMARY KEY,
    user_id          BIGINT       NOT NULL,
    created_at       TIMESTAMP    NOT NULL,
    last_seen_at     TIMESTAMP    NOT NULL,
    absolute_expiry  TIMESTAMP    NOT NULL,
    idle_expiry      TIMESTAMP    NOT NULL,
    ip_address       VARCHAR(45)  NULL,
    user_agent_hash  VARCHAR(64)  NULL,
    auth_level       VARCHAR(20)  NOT NULL,
    revoked_at       TIMESTAMP    NULL
);

CREATE INDEX idx_sessions_user
    ON user_sessions (user_id, revoked_at);

Storing the user identifier alongside the session allows a critical operation: terminating every active session for one user in a single statement.

UPDATE user_sessions
SET revoked_at = CURRENT_TIMESTAMP
WHERE user_id = :user_id
  AND revoked_at IS NULL;

Session Identifier Requirements

JSON Web Tokens

A JWT is a self-contained, signed statement. It carries its claims in the token itself, so a recipient holding the correct key can verify it without consulting a central store.

{
    "alg": "RS256",
    "typ": "JWT",
    "kid": "signing-key-2026-09"
}

{
    "iss": "https://identity.example.com",
    "sub": "user-4821",
    "aud": "orders-api",
    "exp": 1790000900,
    "iat": 1790000000,
    "jti": "tok-9c41e7f2",
    "scope": "orders.read orders.write",
    "auth_level": "mfa"
}

Direct Comparison

The Revocation Problem

Because a JWT is verified locally, the verifier has no natural way to learn that the token should no longer be honoured. Until the expiry claim passes, it remains cryptographically valid.

This window matters in concrete situations: a user logs out, an account is suspended, a device is reported stolen, a role is downgraded, or an administrator detects a compromise.

Version-Claim Revocation

async function isTokenStillValid(claims) {
    const cacheKey = `session-version:${claims.sub}`;

    let currentVersion = await cache.get(cacheKey);

    if (currentVersion === null) {
        currentVersion = await userRepository
            .getSessionVersion(claims.sub);

        await cache.set(cacheKey, currentVersion, {
            ttlSeconds: 60
        });
    }

    return Number(claims.session_version) === Number(currentVersion);
}

Incrementing the stored version invalidates every outstanding token for that user. The cache TTL determines how quickly the change propagates, which is a deliberate freshness decision.

Validating a JWT Properly

async function verifyAccessToken(token, config) {
    const segments = token.split(".");

    if (segments.length !== 3) {
        throw new Error("Malformed token");
    }

    const header = decodeSegment(segments[0]);

    if (!config.allowedAlgorithms.includes(header.alg)) {
        throw new Error("Algorithm not permitted");
    }

    const key = await keyStore.getKey(header.kid);

    if (!key) {
        throw new Error("Unknown signing key");
    }

    const signatureValid = await verifySignature(
        `${segments[0]}.${segments[1]}`,
        segments[2],
        key,
        header.alg
    );

    if (!signatureValid) {
        throw new Error("Signature verification failed");
    }

    const claims = decodeSegment(segments[1]);
    const nowSeconds = Math.floor(Date.now() / 1000);
    const skew = config.clockSkewSeconds;

    if (claims.iss !== config.expectedIssuer) {
        throw new Error("Issuer mismatch");
    }

    const audiences = Array.isArray(claims.aud)
        ? claims.aud
        : [claims.aud];

    if (!audiences.includes(config.expectedAudience)) {
        throw new Error("Audience mismatch");
    }

    if (claims.exp + skew < nowSeconds) {
        throw new Error("Token expired");
    }

    if (claims.nbf && claims.nbf - skew > nowSeconds) {
        throw new Error("Token not yet valid");
    }

    if (await denyList.contains(claims.jti)) {
        throw new Error("Token revoked");
    }

    return claims;
}

Cookie Configuration

Whether you carry a session identifier or a token, cookie attributes determine much of the practical security posture.

Set-Cookie: sid=9f2b71c4a83e5d06;
    HttpOnly;
    Secure;
    SameSite=Lax;
    Path=/;
    Max-Age=1800

Where Browser Clients Should Store Credentials

Cross-Site Request Forgery

Cookies are attached automatically by the browser, which is convenient and also the root of CSRF. A malicious page can trigger a request that carries the victim's cookie.

Expiry Policies

A robust design applies more than one expiry rule, because idle abandonment and long-running compromise are different risks.

The Hybrid Pattern

Most mature systems do not choose one model exclusively. They combine a server-managed session at the edge with short-lived tokens for internal calls.

1. The user authenticates and receives an HttpOnly session cookie.
2. The edge service holds the authoritative session record.
3. Each request resolves the session and confirms it is active.
4. The edge mints a short-lived token scoped to the downstream call.
5. Internal services verify that token locally without a lookup.
6. Logout revokes the session, ending new token issuance at once.

Choosing Between Them

Signing Key Management

Threats and Mitigations

Monitoring and Detection

Common Design Mistakes

System Design Interview Discussion

Implementation Checklist

Knowledge Check

Summary

Sessions and JWTs both maintain authenticated state across stateless HTTP requests, but they place that state in different locations. A session keeps authority on the server and hands out a meaningless reference. A JWT hands the client a signed statement that any holder of the verification key can validate.

The decisive difference is revocation. Sessions can be terminated instantly, while JWTs remain valid until they expire unless a lookup mechanism is reintroduced, which partially negates their stateless advantage.

Correct JWT handling requires verifying the signature before trusting any claim, enforcing a server-side algorithm allow-list, and validating issuer, audience, and time claims. Correct session handling requires unguessable identifiers, regeneration at login, layered expiry, and genuine server-side logout.

In browsers, credentials belong in HttpOnly, Secure, SameSite cookies rather than local storage. Most large systems adopt a hybrid: a revocable session at the edge, and short-lived tokens verified locally by internal services.