Auth Flow & Security Trade-offs

Sending the Token

GET /api/orders HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

# "Bearer" — whoever holds the token gets access, no further proof required.
# A server verifies the signature + exp/iss/aud, with NO database lookup —
# this statelessness is why JWTs suit horizontally-scaled/microservice APIs.

Access Tokens & Refresh Tokens

// Short-lived access token — used on every API call, bounds the damage
// window if leaked, but generally can't be revoked before it expires
const accessToken = jwt.sign({ sub: user.id }, ACCESS_SECRET, { expiresIn: '15m' });

// Longer-lived refresh token — stored server-side (or as an httpOnly cookie),
// used ONLY to mint new access tokens, and CAN be revoked (delete its DB row)
const refreshToken = jwt.sign({ sub: user.id }, REFRESH_SECRET, { expiresIn: '30d' });
await db.refreshTokens.insert({ userId: user.id, token: refreshToken });

// On logout — revoke by deleting the refresh token's server-side record;
// the access token itself just has to expire naturally (hence keeping it short)
await db.refreshTokens.delete({ token: refreshToken });

Client-Side Storage Trade-off

localStorage is convenient but readable by any JavaScript on the page — vulnerable to XSS-based token theft. An httpOnly cookie is invisible to JavaScript (mitigating XSS) but is sent automatically by the browser, requiring separate CSRF protection. Neither is universally "correct" — the choice depends on which threat (XSS vs CSRF) the application is more exposed to and how it's mitigated elsewhere (CSP, CSRF tokens).

JWS vs JWE

A standard JWT is a JWS (JSON Web Signature) — signed for integrity, but readable by anyone. A JWE (JSON Web Encryption) additionally encrypts the payload, so its contents aren't readable without the decryption key. If a token genuinely needs to carry data the bearer shouldn't be able to read, use a JWE — or better, don't put that data in the token at all.