What are the three components of a JWT?
Tests if you know JWT structure beyond library usage. A strong answer lists header, payload, and signature; notes Base64Url encoding; and gives a registered claim like exp. A red flag is confusing signing with encryption.
WHAT THIS TESTS: Whether a candidate knows the mechanical structure of a JWT or just treats it as an opaque string from a library. At senior level this is table stakes, but interviewers use it to screen for security hygiene: do you know that a signature is not encryption, that the payload is visible, and that the header drives trust.
A GOOD ANSWER COVERS: First, name the three dot-separated parts: the JOSE header, the payload, and the signature. Second, explain the header contains metadata like the signing algorithm and token type. Third, explain the payload is a JSON object containing claims, which can be registered, public, or private. Fourth, explain the signature is computed over the encoded header and encoded payload using the algorithm specified in the header and a secret or key, and it provides integrity and authenticity, not confidentiality. Fifth, give a concrete registered claim example such as exp for expiration time, iat for issued at, iss for issuer, sub for subject, or aud for audience.
COMMON WRONG ANSWERS: Confusing the signature with encryption and stating that JWTs hide their payload. Claiming there are only two parts or omitting the header entirely. Describing the payload as encrypted by default. Saying the secret is sent inside the token. Naming a claim that does not exist in RFC 7519 or describing custom application data as standard claims without distinction.
LIKELY FOLLOW-UPS: How would you handle token revocation in a stateless architecture? What is the difference between JWS and JWE? Why should you avoid the none algorithm? How do you validate a JWT signature on the server? What happens if the client modifies the payload before sending it back?
ONE CONCRETE EXAMPLE: A typical JWT header is Base64Url-encoded and contains alg: HS256 and typ: JWT. The payload contains sub: user_123, exp: 1718900000, and iat: 1718800000. The signature is an HMACSHA256 hash of the encoded header, a dot, and the encoded payload, signed with a server-side secret. Anyone can Base64Url-decode the first two parts to read the claims, but only the server can produce or verify the signature.
Source: RFC 7519
Read the original → rfc-editor.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.