Explain the structure of a JWT.
A JWT consists of three parts: Header, Payload, and Signature. These parts are base64 encoded and concatenated with dots. The structure looks like header.payload.signature.
- 1
Header: The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
- 2
Payload: The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims. The payload is then Base64Url encoded to form the second part of the JSON Web Token.
- 3
Signature: The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.
Scenario Questions
- 1
Imagine you're building a login flow and need to store the user's role in a JWT. If you decode the token on the frontend and see the payload is just Base64 encoded, does that mean any user can easily modify their role to 'admin' and bypass your security? How does the backend detect this?
- 2
We have a bug where a frontend developer is trying to read the user's email from a JWT, but they are getting a parsing error. If I show you a raw JWT string, how would you split it up to find where the email payload actually lives, and what tool or method would you use to decode it?
- 1
We recently migrated our auth to JWTs. A developer noticed that our token payloads are getting quite large because we're storing user permissions, preferences, and profile data inside them. Users are now complaining about slow page loads on mobile. Why is this happening, and how would you restructure the token or our architecture to fix it?
- 2
During a security audit, we discovered that our backend was accepting JWTs with the algorithm header set to 'none', allowing attackers to forge admin tokens. How does the structure of a JWT enable this vulnerability, and how would you patch our verification middleware to prevent it?
- 1
We are designing a multi-tenant SaaS platform where tenants can bring their own identity providers (IdPs). How would you design our API gateway's JWT validation layer to dynamically verify signatures from different issuers without hardcoding public keys or killing our API latency?
- 2
We need to implement a 'log out of all devices' feature, but we are currently using stateless JWTs. Given that JWTs are self-contained and valid until they expire, how would you design a high-performance revocation strategy that doesn't completely defeat the purpose of using stateless tokens?
- 1
Our enterprise is moving from a monolithic session-based auth to a decentralized microservices architecture using JWTs. Some teams want to use JWE (encrypted JWTs) to hide internal user metadata, while others want standard JWS (signed JWTs) for performance. How would you evaluate this architectural decision, and what standards would you establish for token lifecycle, key rotation, and trust boundaries across 50+ microservices?
- 2
We are deprecating a legacy proprietary token system in favor of JWTs across our entire product suite, which includes web, mobile, and third-party integrations. How would you design a zero-downtime migration strategy that handles token translation, key distribution, and backward compatibility during the transition period?
Follow-up Questions
- ❓What happens if an attacker changes the 'alg' header to 'none'?
- ❓How do you handle token revocation before the expiration time?
- ❓Where should you store a JWT on the client side to prevent XSS and CSRF?