Hard20 minWeb Fundamentals
UpdatedAug 5, 2026
Edit

Secure JWT validation

CONCEPTS:JWT SecuritySession vs. Token Authentication (JWT)

Question Variations

  • "Why is accepting the JWT alg header blindly dangerous?"
  • "What claims should an API validate?"
  • "How do key rotation and JWKS work?"
  • "How can a JWT be revoked before expiration?"

Why This Is Asked

JWTs are easy to decode, which can lead teams to confuse readable claims with trusted claims. Interviewers use this question to test cryptographic validation, strict claim checking, key management, and the limits of stateless revocation.

Key Concepts

  • Signature verification: Decode is not verification; accept only configured algorithms and trusted keys.
  • Registered claims: Enforce expiration, issuer, audience, and any application-required claims.
  • Token purpose: Do not accept a token issued for one resource server or client at another.
  • Confidentiality: A signed JWS payload is readable; use encryption only when the design requires it.

Question Variations

  • “Why is accepting the JWT alg header blindly dangerous?”
  • “What claims should an API validate?”
  • “How do key rotation and JWKS work?”
  • “How can a JWT be revoked before expiration?”

Answers by Technology

+ Add Variant
System DesignImprove this answer ✏️

Expected Answer (JWT BCP / RFC 8725)

JWT validation starts with treating an incoming token as untrusted. Base64url decoding reveals claims but provides no proof that they were issued by a trusted party. A verifier must use trusted key material, restrict the accepted algorithms rather than trusting the token header, and verify the JWS signature. It must then enforce application-specific claims: at minimum expiration, issuer, and audience, plus token type, scopes, and any subject or authorization requirements relevant to the endpoint.

Keys should be obtained from a trusted configured issuer, commonly through a JWKS endpoint, and rotated with kid handling. Do not let an attacker choose an arbitrary JWKS URL or accept an algorithm/key-type mismatch. A signed JWT is not encrypted, so never put secrets or sensitive personal data in its payload unless it is intentionally encrypted and recipients are designed to decrypt it. Keep access tokens short lived; early revocation requires state, such as deny-listing, token introspection, or a session/token version check.

Why It Matters

Skipping signature, issuer, audience, or algorithm validation can turn a token issued for another service—or a forged token—into unauthorized access. These are high-impact boundary checks that must be centralized and tested.

Example Code

import { createRemoteJWKSet, jwtVerify, type JWTPayload } from 'jose';

const issuer = 'https://issuer.example';
const audience = 'https://api.example';
const keys = createRemoteJWKSet(new URL(`${issuer}/.well-known/jwks.json`));

export async function verifyAccessToken(token: string): Promise<JWTPayload> {
  const { payload } = await jwtVerify(token, keys, {
    issuer,
    audience,
    algorithms: ['ES256'],
  });
  if (payload.typ !== 'at+jwt') throw new Error('Unexpected token type');
  return payload;
}

Common Mistakes

  • Only decoding the token: Decoding is formatting, not cryptographic verification, so forged claims are accepted.
  • Accepting whatever algorithm the header requests: Algorithm confusion attacks become possible; pin the allowed algorithms and key type.
  • Checking expiration but not audience: A valid token issued to a different API can be replayed at this API.

Follow-up Questions

  • How does JWT key rotation work? (Answer: Publishers expose multiple public keys with IDs; verifiers select a trusted key by kid and refresh the trusted key set.)
  • Can JWTs be revoked immediately? (Answer: Not purely statelessly; introduce server-side state or use short expiration plus an appropriate revocation mechanism.)

References