Authentication Foundations: Sessions, Tokens, and Trust

Authentication is mostly a series of trade-offs you cannot postpone: server-side session vs. self-contained token, password vs. passkey, RBAC vs. ABAC, immediate revocation vs. horizontal scale. This article gives a senior engineer the smallest mental model that lets you make those calls deliberately, the current 2026 source-of-truth parameters for the cryptographic and protocol pieces, and pointers to the deeper sibling articles in the Web Security & Authentication series — OAuth & OIDC Flow Guide, CSRF and CORS Defense, Web App Security Architecture, and the OWASP Top 10 Guide — that cover the broader threat model.

Mental model

Three orthogonal questions, asked in order on every protected request:

1. Authentication (AuthN) — who is the calling principal? Verified via a credential the caller proves they hold (password + factor, possession of a private key, a previously issued session/token).
2. Authorization (AuthZ) — what is that principal allowed to do on this resource right now? Decided by a policy that consumes identity claims, resource attributes, and environment.
3. Accounting — what did the principal actually do? An immutable audit trail that feeds anomaly detection, incident response, and compliance.

Two invariants worth holding in your head before you read further:

• Sessions vs. tokens is an architectural choice, not a security ranking. Either can be secure; they fail in different ways and scale through different mechanisms.
• Bearer tokens (JWT, OAuth access tokens, opaque session IDs) cannot be truly revoked without infrastructure. You either accept short lifetimes, run a revocation list, or sender-constrain the token to a key the client holds (RFC 9700, §4.13–4.14).

Common terms used throughout, defined exactly once:

Sessions vs. tokens

Server-side sessions and self-contained tokens both move bytes between client and server on every request; what differs is where the trust state lives and what the server has to do to evaluate it.

How each one actually works

Session cookies. The server generates a high-entropy opaque ID, persists {sid → {userId, roles, expiresAt}} in a session store (Redis, Postgres, Memcached), and sets the ID in a cookie scoped to the application’s origin. Each request carries the cookie; the server reads the store, applies an idle-timeout check, and rolls the expiry. Logout deletes the row, killing every device using that session. Cookies are managed by the browser and are subject to the SameSite, Secure, HttpOnly, and Partitioned attributes — see csrf-and-cors-defense for the cross-site attack surface.

JWT (or any self-contained token). The authorization server signs a JSON payload containing the user’s identity claims and an expiry. Anyone who holds the issuer’s verification key (symmetric secret or, more commonly, a public key fetched from a JWKS endpoint) can validate the token without I/O. The token is opaque to the client but readable to anyone who base64-decodes it; never put secrets in JWT claims (RFC 7519, §10.1).

Trade-off matrix

When to pick what

Choose server sessions when:

• You can tolerate the session-store dependency (it’s almost always a single point of failure for auth — design accordingly).
• You need immediate, reliable revocation — banking, healthcare, internal admin tools.
• The frontend and backend share an origin and SameSite=Lax does the CSRF heavy lifting for you.
• You want to be able to introspect a live session (“kill all sessions for user X”, “show me all devices logged in as Y”).

Choose self-contained tokens when:

• You’re crossing origins or boundaries between independently deployed services (typical SPA/microservices/mobile).
• Per-request session-store latency is unacceptable (high-fan-out APIs, edge functions).
• You can live with revocation being eventual, and you’re prepared to run refresh-token rotation (below).

The de facto pattern for modern web SPAs is the hybrid: a short-lived JWT access token kept in JavaScript memory, plus a refresh token in an HttpOnly; Secure; SameSite=Strict cookie. Memory storage means XSS cannot exfiltrate the access token from disk; HttpOnly keeps the refresh token completely out of JavaScript’s reach. Backed by refresh-token rotation, this gives you JWT scalability with most of the revocation properties of a session.

Refresh-token rotation, the right way

Long-lived refresh tokens are the single biggest revocation gap in JWT-based auth. RFC 9700 (the OAuth 2.0 Security Best Current Practice, January 2025) requires that refresh tokens for public clients are either sender-constrained (DPoP from RFC 9449, or mutual-TLS from RFC 8705) or rotated on every use with reuse detection.

The rotation pattern, with a “token family” tracked server-side:

The non-obvious part is reuse detection. The legitimate client only ever holds the latest refresh token; if the previous one is presented, you have observed a clone. The correct response is to revoke every token in the family — including currently valid access tokens — and force re-authentication. Auth0, Okta, Descope, and most modern auth services implement exactly this.¹

Credentials

Password storage

If you must accept passwords, the storage choice is settled. The current OWASP Password Storage Cheat Sheet ranks algorithms in this order, with these minimum parameters:

The tuning rule is target 200–500 ms per hash on the production hardware that does login traffic, then re-tune annually as hardware improves. Below 100 ms is too cheap; above ~1 s and authentication latency starts to dominate user perception and you have effectively built a self-DoS amplifier on /login.

1import argon2 from "argon2"23const ARGON2_OPTIONS = {4  type: argon2.argon2id,5  memoryCost: 19 * 1024,6  timeCost: 2,7  parallelism: 1,8} as const910export async function hashPassword(plain: string): Promise<string> {11  return argon2.hash(plain, ARGON2_OPTIONS)12}1314export async function verifyPassword(plain: string, hash: string): Promise<boolean> {15  const ok = await argon2.verify(hash, plain)16  if (ok && argon2.needsRehash(hash, ARGON2_OPTIONS)) {17    // Lazy migration after a parameter bump: re-hash in the same login request18    // and write the new digest back to the database.19  }20  return ok21}

A few non-obvious notes:

• bcrypt’s 72-byte input limit is a real footgun. If you let users paste a passphrase, every byte after the 72nd is silently ignored — and worse, two different long passphrases that share a 72-byte prefix collide. The OWASP-recommended workaround is to pre-hash with HMAC-SHA-256 and Base64-encode before bcrypt, keeping the result under 72 bytes.²
• Stop enforcing composition rules. NIST SP 800-63B-4 (Digital Identity Guidelines: Authentication and Authenticator Management, July 2025) explicitly bans mandatory composition rules and arbitrary periodic rotation, formalising guidance that has been in the document since the 2017 SP 800-63B Rev. 3. Enforce a long minimum (the new floor is 15 characters when the password is the sole authenticator), screen against a breached-password corpus, and otherwise let users choose.
• “Pepper” if you can. A server-side secret prepended to the password before hashing protects you against database-only compromise (the attacker has the digests but not the pepper). Trade-off: rotating the pepper means a forced password reset across the user base, so tie it to the same secret-rotation cadence as your signing keys.

Multi-factor authentication

A factor is meant to come from a different category than the others: knowledge (password), possession (a device or hardware key), or inherence (biometric). Two passwords are not two factors.

The practical hierarchy from worst to best, as of 2026:

If you only ship one factor beyond a password, ship a passkey.

WebAuthn and passkeys

WebAuthn is a public-key credential protocol standardised by the W3C and FIDO Alliance. The authenticator (Touch ID, Windows Hello, a YubiKey, an Android secure enclave) holds the private key; the relying party stores only the public key. The authenticator signs an origin-bound challenge — and that origin binding is the entire reason passkeys defeat phishing.

The mechanism: when the browser calls navigator.credentials.create() or .get(), it includes the current top-level origin in the clientDataJSON blob the authenticator signs. The authenticator additionally checks that the call’s rpId is the registered Relying Party. A credential registered for bank.com cannot be exercised on bank.com.evil.example — the authenticator simply refuses.³ No amount of social engineering changes that.

Status as of 2026-Q2:

• WebAuthn Level 3 is a W3C Candidate Recommendation Snapshot, published 2026-01-13. New in L3: client capability discovery, supplemental public keys, cross-origin authentication via <iframe> with explicit RP opt-in, and explicit signaling for credential backup state.
• Synced passkeys (Apple iCloud Keychain, Google Password Manager, Microsoft account, plus third-party managers like 1Password and Bitwarden) roam credentials across the user’s devices in a single ecosystem; the credential is the same key material everywhere.
• Cross-ecosystem portability (e.g. Apple → Google) is not yet generally available. The FIDO Alliance Credential Exchange Format (CXF) — Proposed Standard, August 2025 — defines what gets moved; the Credential Exchange Protocol (CXP), still in working draft, defines how. Apple’s iOS/macOS 26 ships a same-device CXF-based transfer flow; full cross-provider exchange is an in-progress story for late 2026.⁴

JWT mechanics and security

If you’re using JWTs, the failure modes you have to design against are nearly all in the verification path.

Anatomy

A JWT is three base64url-encoded segments joined with dots: header.payload.signature. The header declares the algorithm (alg) and key id (kid); the payload carries the claims; the signature covers header.payload.

The standard registered claims you should always set and always verify:

Algorithm selection

Pick the algorithm based on whether the verifier can hold the signing secret.

The four JWT footguns you must defend against

1. alg: none. RFC 7519 §6.1 defines an “unsecured” JWT with no signature. Some libraries accept it by default. Strip the signature, set alg to none, and a vulnerable verifier passes the token. Defence: never verify with the algorithm taken from the token’s header — pin the algorithm in the call.
2. Algorithm confusion (RS256 → HS256). A library that accepts both asymmetric and symmetric algorithms can be tricked into using the public key as if it were an HMAC secret. Since the public key is, by design, public (often via JWKS), the attacker forges valid HMAC signatures.⁶ Defence: explicit allowlist of expected algorithms in jwt.verify(token, key, { algorithms: ["EdDSA"] }).
3. kid injection. The kid header tells the verifier which key to look up. If the verifier reads kid as a filesystem path or SQL fragment, you have a path-traversal / SQL-injection bug feeding into your trust root. Defence: treat kid as an opaque string keyed into a map populated from your trusted JWKS; never as a file path.
4. Missing aud / iss checks. A token issued by your IdP for service A is happily accepted by service B if B does not check aud. Defence: every verifier validates iss, aud, and exp every time, in addition to the signature.

1import jwt, { type JwtPayload } from "jsonwebtoken"2import { JwksClient } from "jwks-rsa"34const jwks = new JwksClient({5  jwksUri: process.env.JWKS_URI!,6  cache: true,7  rateLimit: true,8})910const ALLOWED_ALGS = ["EdDSA"] as const1112export async function verifyAccessToken(token: string): Promise<JwtPayload> {13  return new Promise((resolve, reject) => {14    jwt.verify(15      token,16      (header, cb) => {17        jwks18          .getSigningKey(header.kid)19          .then((key) => cb(null, key.getPublicKey()))20          .catch(cb)21      },22      {23        algorithms: ALLOWED_ALGS,24        issuer: process.env.JWT_ISSUER,25        audience: process.env.JWT_AUDIENCE,26      },27      (err, decoded) => (err ? reject(err) : resolve(decoded as JwtPayload)),28    )29  })30}

Revoking JWTs

Strictly, you cannot. The token is a signed self-describing claim; once it’s out, anyone can verify it until exp. The four production patterns:

• Short access-token TTL + refresh rotation. The cheapest, most common pattern. 5–15 min for sensitive APIs, 15–30 min for general use. Compromise window equals the access-token TTL.
• Denylist by jti. A per-jti “revoked until exp” entry in Redis or a Bloom filter at the API gateway. Cheap if the denylist is small; turns into a hot path if you revoke aggressively.
• Sender-constrained tokens (DPoP / mTLS). The token is bound to a client-held key. Stealing the token alone is useless because the verifier requires a fresh proof-of-possession on each request (RFC 9449, RFC 8705).
• Key rotation as panic button. Rotate the signing key and invalidate the JWKS entry to revoke every token in one action. Useful for “we have been breached, log everyone out” — destructive, so reserve it for incidents.

Authorization: RBAC, ABAC, and ReBAC

Once authentication has produced an identity, authorization decides what they can do. The three families you will hit in real systems:

RBAC — Role-Based Access Control

Permissions attach to roles; users are assigned roles. The model is formalised in NIST INCITS 359 (RBAC). It works because most real-world permission requirements track job function, not individual users.

RBAC’s failure mode is role explosion. The moment a permission depends on the resource (“only your own documents”) or context (“only during business hours”), pure RBAC starts spawning roles like editor-team-A-monday-thru-friday-9-to-5. When you find yourself doing that, you’ve outgrown RBAC.

1type Permission = `${string}:${"create" | "read" | "update" | "delete"}`23const rolePermissions = new Map<string, Set<Permission>>([4  ["admin", new Set(["user:create", "user:read", "user:update", "user:delete"])],5  ["editor", new Set(["user:read", "user:update"])],6  ["viewer", new Set(["user:read"])],7])89export function userHasPermission(roles: string[], permission: Permission): boolean {10  return roles.some((r) => rolePermissions.get(r)?.has(permission) ?? false)11}1213export function requirePermission(permission: Permission) {14  return (req, res, next) => {15    if (!req.user) return res.status(401).json({ error: "unauthenticated" })16    if (!userHasPermission(req.user.roles, permission)) {17      return res.status(403).json({ error: "forbidden" })18    }19    next()20  }21}

ABAC — Attribute-Based Access Control

Decisions are computed from attributes of subject, resource, action, and environment. The reference is NIST SP 800-162. ABAC handles the contextual cases RBAC chokes on (“a doctor can read a chart only if assigned to that patient and they are on shift”), at the cost of a real policy engine you have to author, version, and reason about.

The standard production options:

• OPA / Rego. Open Policy Agent runs as a sidecar or library; policies are decoupled from application code. Best when many services share the same policy.
• AWS Cedar / Amazon Verified Permissions. Cedar is a typed, formally analysable policy language; Verified Permissions is the managed evaluator. Strong if you’re already on AWS.
• In-process policy code. Fine for small surface areas; sets up a future refactor into a real engine.

ReBAC — Relationship-Based Access Control

When permissions are graph-shaped — “you can read a document if you are in any group that has been granted access, transitively” — RBAC and ABAC both struggle. The dominant ReBAC implementations (SpiceDB, OpenFGA, Google’s internal Zanzibar) model authorization as a relationship graph and answer “can user:alice perform read on document:42?” by traversing it. Useful for collaboration products (Drive, Notion, Figma) where the permission is the relationship.

Choosing

The pragmatic path is RBAC first, ABAC where it actually pays for itself, ReBAC only if your domain is genuinely a permission graph. Migrating from RBAC to ABAC later is straightforward; ripping a misapplied ReBAC out of a product that didn’t need it is not.

Cookie security primer

If you ship sessions or refresh tokens via cookies, the attribute set is doing the heavy lifting. The current 2026 defaults:

The deeper CSRF / CORS story — how SameSite interacts with OPTIONS preflights, when you still need a CSRF token, the Origin-header strategy — lives in csrf-and-cors-defense.

Operational guardrails

Authentication is one of the few subsystems where the failure mode is “user account silently taken over weeks ago.” Treat the operational pieces as load-bearing.

• Rate-limit /login, /refresh, /reset per identity and per IP. Per-identity catches credential-stuffing against a single user; per-IP catches a botnet hitting many users. Exponential back-off plus a temporary lockout after ~5–10 failures is standard. Always return a constant-time and constant-shape response — never reveal whether the email exists.
• Detect anomalies in real time. Impossible-travel (login from two countries inside a token’s TTL), new-device sign-in, MFA-fatigue patterns (lots of denied push prompts), and refresh-token reuse should each trigger an account-level signal that can step-up authentication or alert security ops.
• Audit every auth event with an immutable, queryable trail. Login success/failure, token issue/refresh/revoke, MFA enrolment changes, password change, recovery flow — log them with userId, sessionId, jti, IP, user-agent, and a stable correlation id. The audit log is what you’ll wish you had when you’re the one writing the breach disclosure.
• Plan the incident response before the incident. The runbooks you need: revoke a single user’s tokens, rotate a signing key (and what breaks when you do), purge a session-store partition, force MFA re-enrolment across a tenant.
• Recovery is the auth surface. A passkey-protected account whose recovery is “click a link in your email” inherits the security of email. Recovery flows must equal the assurance of the strongest enrolment factor — that usually means a second passkey, a recovery code locked at registration, or a verified-identity step.
• Re-tune your hashing cost annually. Hardware moves; what was 250 ms on 2023 hardware may be 80 ms today. Use argon2.needsRehash() (or the bcrypt/scrypt equivalent) on every successful login and lazily migrate to current parameters.

Where this fits in the rest of the series

This article deliberately stops short of OAuth/OIDC mechanics, the full CSRF/CORS attack surface, and the broader application threat model. Continue with:

• oauth-oidc-flow-guide — Authorization Code with PKCE, OIDC discovery, ID-token vs access-token semantics.
• csrf-and-cors-defense — SameSite, CSRF tokens, the Origin header, CORS preflights.
• web-app-security-architecture — CSP, security headers, threat-modelling the front end.
• csp-violation-reporting-pipeline — operationalising CSP at scale.
• owasp-top-10-guide — the broader risk catalogue this article assumes you’ll layer on top.

A note on Zero Trust: “never trust, always verify” (NIST SP 800-207) is an architectural posture for the whole network and identity plane, not an authentication primitive. The pieces in this article — short-lived tokens, sender-constraining, continuous verification via reuse detection and anomaly signals, default-deny ABAC — are how you implement Zero Trust at the application layer. The framework deserves its own deep dive elsewhere.

References

Specifications and standards

• draft-ietf-httpbis-rfc6265bis-22 — current cookie semantics including SameSite, Secure, HttpOnly, Partitioned (RFC Editor queue, Dec 2025).
• RFC 6238 — TOTP.
• RFC 6749 — OAuth 2.0 Authorization Framework.
• RFC 6750 — Bearer Token Usage.
• RFC 7519 — JSON Web Token.
• RFC 7636 — OAuth PKCE.
• RFC 8252 — OAuth 2.0 for Native Apps.
• RFC 8628 — OAuth 2.0 Device Authorization Grant.
• RFC 8705 — Mutual-TLS sender-constrained tokens.
• RFC 9068 — JWT profile for OAuth 2.0 access tokens.
• RFC 9449 — DPoP.
• RFC 9700 — OAuth 2.0 Security BCP (January 2025).
• draft-ietf-oauth-v2-1-15 — OAuth 2.1 (Working Group document, March 2026; not yet submitted to the IESG).
• WebAuthn Level 3 — W3C Candidate Recommendation Snapshot, 2026-01-13.
• OpenID Connect Core 1.0.

NIST

• SP 800-63-4 / 800-63B-4 — Digital Identity Guidelines, authentication assurance levels (final, July 2025; supersedes SP 800-63-3).
• SP 800-162 — ABAC.
• SP 800-207 — Zero Trust Architecture.
• INCITS 359 — RBAC.

OWASP

• Password Storage Cheat Sheet.
• Authentication Cheat Sheet.
• Authorization Cheat Sheet.

Practitioner references

• Auth0 — Refresh Token Rotation.
• PortSwigger Web Security Academy — JWT attacks.
• FIDO Alliance — Credential Exchange Specifications.
• MDN — Partitioned cookies (CHIPS).