What JWT claims must you validate beyond the signature?

WHAT THIS TESTS: Whether you understand that a valid cryptographic signature only proves the token was issued by a key you trust, not that the token is currently valid, intended for your service, or safe from algorithm substitution. The interviewer wants to see defense-in-depth for token validation in a production FastAPI dependency.

A GOOD ANSWER COVERS: First, time-based claims: verify exp to reject expired tokens, nbf to reject prematurely used tokens, and optionally iat with a small leeway to tolerate clock skew. Second, issuer and audience binding: verify iss matches the expected identity provider and aud matches your service name to prevent cross-service replay. Third, algorithm whitelisting: pass an explicit algorithms list to PyJWT decode and never derive it from the incoming alg header, per RFC 8725 section 2.1. Fourth, required claims enforcement: use the require option to ensure claims like exp or sub are actually present rather than merely optional. Fifth, subject and JWT ID validation when applicable: verify sub matches the expected user or service principal, and consider jti for one-time token replay prevention in high-security flows.

COMMON WRONG ANSWERS: Saying the signature is enough and skipping all claim checks. Dynamically setting algorithms based on the JWT header, which enables algorithm confusion attacks. Ignoring audience and issuer, allowing tokens minted for other APIs to access your service. Using excessive leeway or disabling exp verification in production. Failing to mention that PyJWT options like verify_exp and verify_aud must remain enabled.

LIKELY FOLLOW-UPS: How would you handle key rotation with a JWKS endpoint. What leeway value do you use in practice, typically 0 to 60 seconds. How do you prevent replay of non-expiring tokens using jti and a cache. What happens if you mix symmetric HS and asymmetric RS algorithms with the same key material.

ONE CONCRETE EXAMPLE: In a FastAPI dependency using PyJWT, you would call jwt.decode with the token, public key, algorithms set to RS256, audience set to my-api, issuer set to auth.example.com, and options requiring exp, iss, and aud, with a leeway of 10 seconds. If the token was signed with HS256 or lacks the aud claim, PyJWT raises InvalidAlgorithmError or MissingRequiredClaimError before your route handler ever executes.