How does JWT authentication work and what are its risks?

A JWT has a header, a payload and a signature. The payload is encoded, not encrypted, so anyone holding the token can read it. The signature lets the issuer's key prove the claims were not modified. The server must verify the algorithm, signature, issuer, audience and expiry.

import jwt from "jsonwebtoken";

const token = jwt.sign(
  { sub: user.id, role: "admin" },
  privateKey,
  {
    algorithm: "RS256",
    expiresIn: "15m",
    issuer: "api.example.com",
    audience: "web",
  },
);

const claims = jwt.verify(token, publicKey, {
  algorithms: ["RS256"],
  issuer: "api.example.com",
  audience: "web",
});

The risks

• Accepting the alg header without allowlisting enables algorithm confusion attacks
• A stolen token works until it expires, so short access token lifetimes matter
• Revocation is hard without a denylist, token version or short-lived refresh flow
• Storing tokens in localStorage exposes them to XSS; httpOnly cookies reduce that risk but need CSRF protection
• Putting secrets or personal data in the payload leaks them, because the payload is readable
• Clock skew can cause valid tokens to be rejected; allow a small leeway

A production setup often uses a short-lived access token and a longer-lived refresh token stored in an httpOnly cookie. Refresh tokens can be rotated and revoked server-side. For high-risk actions, require re-authentication rather than trusting a long-lived claim.