Home → Blog → Auth Token Comparison

JWT vs Session Cookies vs PASETO vs Biscuit — Auth Token Comparison (2026)

"Just use JWT" became the default authentication advice for web applications in the late 2010s, and the consequences are still being felt. JWT is genuinely useful for some scenarios — and an actively bad choice for others. Meanwhile, alternatives that addressed JWT's footguns have matured: PASETO removed the algorithm-confusion problem at the protocol level, Biscuit added offline attenuation, and server-side session cookies — the option JWT was supposed to replace — remain the simplest secure default for the vast majority of web applications. This article compares the four most relevant token approaches in 2026: JWT, server-side session cookies, PASETO, and Biscuit. The recommendation at the end is opinionated and grounded in the security literature.

The Comparison at a Glance

Property	JWT	Server-side session	PASETO	Biscuit
Stateless (no server lookup)	Yes	No	Yes	Yes
Easy revocation	No (or stateful)	Yes	No (or stateful)	Partial
Algorithm-confusion attacks possible	Yes (alg header)	N/A	No (versioned)	No
Confidentiality of claims	No (just base64)	Yes (server-only)	v*.local: Yes	No
Offline attenuation / delegation	No	No	No	Yes
Storage in browser	Cookie / localStorage	HttpOnly cookie (best)	Cookie / localStorage	Cookie / localStorage
Library maturity (Node)	Excellent	Excellent	Good	Limited
Cross-language support	Excellent	N/A (server-internal)	Good	Limited
RFC / standard	RFC 7519	De facto	PASETO spec	Biscuit spec

Server-Side Session Cookies

The traditional approach: when a user logs in, the server creates a session record (in Redis, in a database, or in memory), generates an opaque random session ID, and sets that ID in an HttpOnly cookie. On every request, the server looks up the session record by ID.

// Express + express-session
import session from "express-session";
app.use(session({
  secret: process.env.SESSION_SECRET,
  cookie: { httpOnly: true, secure: true, sameSite: "lax", maxAge: 86400000 },
  store: new RedisStore({ client: redis }),
  resave: false,
  saveUninitialized: false,
}));

JWT (JSON Web Token)

JWT is a self-contained token: the user's claims (id, role, expiry) are encoded into the token itself, signed by the server. The server validates the signature on every request without consulting a session store.

// Three base64url parts joined by dots
header.payload.signature

// Example payload (decoded):
{
  "sub": "user_123",
  "role": "admin",
  "iat": 1714780000,
  "exp": 1714783600
}

If you must use JWT, do this

• Use asymmetric signatures (RS256, ES256, or EdDSA) — never HS256 with a shared secret across services.
• Validate the algorithm explicitly in your verifier, do not let the token decide.
• Set short access-token lifetimes (5–15 min). Pair with a server-side refresh-token store.
• Store the access token in an HttpOnly cookie if it lives in a browser. localStorage exposes it to any XSS.
• Validate every claim: iss, aud, exp, nbf, sub.
• Never put sensitive data in the payload — it is not encrypted.
• Use a decoder to inspect tokens during development. Never trust unverified claims.

PASETO (Platform-Agnostic Security Tokens)

PASETO is JWT's successor, designed by security researchers (notably Scott Arciszewski) to remove JWT's cryptographic footguns. The core idea: tokens have a version that fixes the algorithm. There is no alg header to manipulate.

// PASETO v4.public token (Ed25519 signed, claims visible like JWT)
v4.public.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6IjIwMjYtMDUtMDNUMTI6MDA6MDBaIn0.aBcDeFg...

// PASETO v4.local (XChaCha20-Poly1305 encrypted, claims confidential)
v4.local.RnB1RQg...

The format is similar to JWT (header.payload.signature) but with critical differences:

• Version determines the algorithm. v4.public = Ed25519. v4.local = XChaCha20-Poly1305. No negotiation, no choice.
• Two purposes: local tokens are encrypted (claims hidden), public tokens are signed (claims visible).
• No alg:none, no algorithm confusion.
• Same self-contained model as JWT — stateless validation.

Biscuit

Biscuit is a 2021-era token format with a unique feature: offline attenuation. A token holder can derive a more restricted token without contacting the server. The new token cannot grant more permissions than the original — only less.

This solves a real problem: delegation. If your user wants to grant a third-party tool read-only access to a single project, the user can attenuate their existing token offline rather than going through an OAuth dance.

Biscuit also has a Datalog-like policy language baked into the token, so authorization decisions can be made at the API gateway without consulting the application.

Decision Tree

1. Is this a single-domain web application with a server you control? → Server-side session cookies. The simplest secure choice.
2. Is this a microservices architecture where services can't share a session store? → JWT or PASETO. Prefer PASETO if the team can adopt it; JWT if you need broad ecosystem compatibility (especially with identity providers).
3. Are you integrating with Auth0, Cognito, Firebase Auth, Clerk, or another identity provider? → JWT. The provider speaks JWT; using anything else means re-implementing auth.
4. Do you need delegation / offline attenuation as a first-class feature? → Biscuit, or build a custom token format. Most teams do not need this.
5. Do you need claims confidentiality (the client should not see the contents)? → PASETO v*.local, or a server-side session, or encrypt the JWT payload separately (uncommon).
6. Is performance a real concern (10k+ req/sec)? → JWT or PASETO with cached public-key validation. Server-side sessions add a Redis round-trip per request.

The Honest Recommendation for 2026

• Default for new web applications: server-side sessions with HttpOnly+Secure+SameSite cookies. Boring, well-understood, easy to revoke. The "JWT for everything" advice from the late 2010s was overcorrected; sessions remain the simpler choice for most use cases.
• For microservices or third-party API authentication: JWT. Pair with short-lived access tokens + server-side refresh tokens for revocation.
• If you have the freedom to choose and the team is comfortable with newer tooling: PASETO. Fewer footguns, same stateless model.
• If you're building a system with explicit delegation requirements: evaluate Biscuit.
• If you're stuck with JWT (you probably are at some level): use asymmetric signing, validate algorithm explicitly, keep tokens short-lived, store in HttpOnly cookies, and never trust unverified claims.

Storage Pitfalls in the Browser

Whatever token format you choose, the storage decision in the browser is critical:

Storage	XSS-readable?	CSRF-vulnerable?	Recommended?
localStorage	Yes (any script)	No	No (avoid for credentials)
sessionStorage	Yes	No	No (avoid for credentials)
Cookie (HttpOnly + Secure + SameSite=Strict/Lax)	No	Mitigated by SameSite	Yes (best for browsers)
In-memory JS variable	Yes (page-level)	No	OK for short-lived in-page state

Putting a JWT in localStorage so you can send it as a Bearer header sounds clean but is a regression in security from a session cookie. If your app runs in a browser, you almost always want HttpOnly cookies — at which point much of the JWT story is just adding cryptographic signatures to data the server could have stored in Redis.

Common Misconceptions

"JWT is encrypted"

Almost always false. The default JWT (JWS) is signed, not encrypted. Anyone who has the token can base64-decode it and read every claim. JWE provides encrypted JWT but is rare and complex; PASETO v*.local is the cleaner option if you need confidentiality.

"JWT is faster than sessions"

Only sometimes. JWT validation is a signature check (microseconds with ECDSA). Session validation is a Redis lookup (sub-millisecond on a local network). For a single request, the difference is rounding error. For 100k req/sec on a global edge with no Redis nearby, JWT wins. For a typical web app, the performance difference is irrelevant.

"JWT solves single sign-on"

Not by itself. SSO is solved by OAuth 2.0 and OIDC, which often use JWT as the access token format but also include flows for issuance, consent, and revocation. JWT alone is a token format, not an SSO protocol.

"JWT can't be stolen because it's signed"

Wrong. Signing prevents tampering, not theft. A stolen JWT is valid until it expires. This is exactly why short expiry + refresh tokens is essential, and why server-side sessions (which can be revoked instantly) remain attractive.

Practical Tooling

Whichever token format you settle on, you'll spend time inspecting and debugging tokens:

• JWT Decoder — paste any JWT to see header, payload, signing algorithm, and claim expiry status.
• JWT Tutorial — start-from-zero introduction to JWT with worked examples.
• paseto.io — PASETO specification and library list.
• biscuitsec.org — Biscuit specification and Rust implementation.
• RFC 7519 — the canonical JWT specification.
• RFC 8259 — the JSON spec underlying JWT/PASETO payload encoding.

Frequently Asked Questions