21 Advanced JWT Authentication Interview Questions for Experienced Developers

A JWT consists of three parts, separated by dots (`.`):

1. Header: A Base64Url-encoded JSON object containing metadata about the token, such as the signing algorithm (`alg`) and token type (`typ`).
2. Payload: A Base64Url-encoded JSON object containing the “claims”—statements about an entity (typically, the user) and additional data.
3. Signature: A cryptographic signature created by taking the encoded header, the encoded payload, a secret, and signing them with the algorithm specified in the header. This is used to verify the token’s authenticity.

• An **Access Token** is a short-lived credential (typically a JWT) that is sent with every API request to authorize the user. Because it’s sent frequently, its short lifespan limits the damage if it’s compromised.
• A **Refresh Token** is a long-lived, opaque token that is stored securely by the client. Its sole purpose is to be sent to the authorization server to obtain a new access token when the old one expires, without requiring the user to log in again.

• `iss` (Issuer): Identifies the principal that issued the JWT.
• `sub` (Subject): Identifies the principal that is the subject of the JWT (typically the user’s ID).
• `aud` (Audience): Identifies the recipients that the JWT is intended for. An API should validate that it is the intended audience of the token.
• `exp` (Expiration Time): The time after which the JWT must not be accepted for processing. This is a critical security measure.
• `jti` (JWT ID): A unique identifier for the token, which can be used to prevent replay attacks or to maintain a blacklist of revoked tokens.

Both are specifications for representing claims, but they have different security goals.

• JWS (JSON Web Signature): This is what most people mean when they say “JWT”. It’s a token whose payload is signed, providing integrity and authenticity. The payload is Base64Url encoded but **not encrypted**, so it is publicly readable.
• JWE (JSON Web Encryption): A JWE is a token whose payload is **encrypted**, providing confidentiality. Only the party with the correct decryption key can read its contents.

You use JWS when you need to verify the sender and that the data hasn’t been tampered with. You use JWE when you need to send sensitive information privately.

Read an overview of JWS and JWE.

• Symmetric (e.g., HS256): Uses a single shared secret key to both sign and verify the token. This is faster and simpler but means any service that needs to validate the token must also have access to the secret key. This is suitable for monolithic applications or tightly coupled services.
• Asymmetric (e.g., RS256): Uses a private key to sign the token and a corresponding public key to verify it. The authorization server holds the private key securely, while resource servers only need the public key. This is much more secure for microservices architectures, as the resource servers do not need access to the sensitive private key.

This is a critical vulnerability where an attacker modifies a JWT by changing the algorithm in the header to `”alg”: “none”`. Some poorly implemented JWT libraries would see this, assume the token was unsecured, and “validate” it without checking any signature at all. This would allow an attacker to forge any payload they want (e.g., `{“isAdmin”: true}`).

Prevention: The server-side validation logic must **never** trust the `alg` header from the token. It must have a pre-configured allow-list of acceptable algorithms (e.g., only `[“RS256”]`) and reject any token that does not specify one of these algorithms.

Read about critical JWT vulnerabilities.

If you store JWTs in `HttpOnly` cookies, your application is still vulnerable to CSRF, just like a traditional session-based app. The browser will automatically send the cookie with malicious cross-site requests. In this case, you must implement standard CSRF protection, such as the synchronizer token pattern (using an anti-CSRF token).

If you store the JWT in Local Storage and send it via an `Authorization` header, you are generally not vulnerable to traditional CSRF attacks, because the browser does not automatically attach this header to cross-site requests.

Read the OWASP CSRF Prevention Cheat Sheet.

A replay attack is where an attacker intercepts a valid JWT and “replays” it to the server to impersonate the user. Since the token is still valid, the server accepts it.

The `jti` (JWT ID) claim provides a unique identifier for each token. To prevent replay attacks, the server can maintain a list of all processed `jti` values. If a token is received with a `jti` that has already been seen, the server can reject the request as a potential replay. This requires a stateful check on the server side.

The `aud` claim identifies the intended recipient (the resource server) of the token. It’s crucial to validate it to prevent a token issued for one API from being used to access another. For example, if `api.service-a.com` receives a token intended for `api.service-b.com`, it should reject it. This ensures that a compromised token from a less critical service cannot be used to gain access to a more sensitive one.

The main risk is **Cross-Site Scripting (XSS)**. If an attacker can inject malicious JavaScript into your web page (e.g., through a vulnerable third-party library or user-generated content), that script runs with the same origin privileges and can access anything in Local Storage. This means it can easily read and steal the JWT, allowing the attacker to impersonate the user completely.

The `kid` header tells the server which key was used to sign the token, which is useful for key rotation. However, it can be a vector for attack if not handled carefully.

A critical security measure is to prevent directory traversal or SQL injection attacks. The server must treat the `kid` value as untrusted input. It should be used only as an identifier to look up a key from a pre-approved list of keys, and never be used, for example, to construct a file path directly (e.g., `load_key(“/keys/” + kid)`).

Immediate server-side revocation of a stateless JWT is a challenge. Common strategies include:

1. Using Short-Lived Access Tokens: This is the most common and simplest approach. With very short expiration times (e.g., 5-15 minutes), the token becomes invalid quickly on its own. The user experience is maintained by using a refresh token to get a new access token seamlessly.
2. Maintaining a Revocation List (Blacklist): The server maintains a list of revoked token IDs (`jti`) or user IDs. On every request, the resource server must check this list to see if the token has been revoked. This re-introduces state but provides immediate revocation.
3. Refresh Token Revocation: Revoking the refresh token is often sufficient, as this prevents the user from obtaining new access tokens.

Explore different JWT Revocation strategies.

Refresh Token Rotation is a security mechanism to detect and prevent refresh token theft. The flow is:

1. A client exchanges a refresh token (`RT_1`) for a new access token.
2. The authorization server returns a new access token AND a new refresh token (`RT_2`). It then invalidates `RT_1`.
3. If an attacker steals and uses `RT_1` after the legitimate client has already rotated it, the authorization server will detect the use of an old, invalidated token.

Upon detecting reuse, the server should immediately invalidate the entire family of refresh tokens for that user, forcing a re-login and mitigating the damage from the stolen token.

Read about Refresh Tokens and Rotation.

• `HttpOnly` Cookies: The token is inaccessible to JavaScript, providing excellent protection against XSS. However, it requires CSRF protection (e.g., synchronizer tokens) because the browser automatically sends cookies with cross-site requests.
• In-Memory (JS Variable): The token is stored in a variable within the SPA’s memory space. This is secure against XSS (as long as you have a strong Content Security Policy) and not vulnerable to CSRF. The main drawback is that the token is lost on a full page reload, requiring a new authentication flow (which can often be done silently with an `HttpOnly` refresh token cookie).

Read a comparison of token storage methods.

A robust client application will intercept API responses. When it receives a `401 Unauthorized` error, it knows the access token has likely expired. At this point, it should:

1. Pause any pending API requests.
2. Use its stored refresh token to silently request a new access token from the authorization server.
3. If successful, it stores the new access token and retries the original failed API request(s).
4. If the refresh token request fails (e.g., it has also expired or been revoked), it should clear all stored tokens and redirect the user to the login page.

A JWKS endpoint is a standardized, public endpoint on an authorization server that exposes the public keys used to sign JWTs. The endpoint returns a JSON object containing a set of JSON Web Keys (JWKs).

This allows resource servers to dynamically fetch the public keys they need to validate incoming JWTs. Each key in the set has a unique Key ID (`kid`), which corresponds to the `kid` in the JWT header. This enables seamless key rotation on the authorization server without requiring any configuration changes on the resource servers.

Learn more about JWKS.

The `id_token` is the core of OIDC. It is a JWT that provides proof of **authentication**. It contains claims about the authentication event itself (when and how the user logged in) and about the user (their unique ID, email, etc.). It is intended to be consumed and validated by the **client application** to establish the user’s identity. It should **not** be sent to a backend API as an access token.

Read the OIDC FAQ.

• Structured Tokens (e.g., JWTs): Contain data within them in a readable format (like JSON). They are self-contained and can be validated by the resource server without contacting the issuer.
• Opaque Tokens: Are random strings of characters that contain no data. They act as a reference pointer. To validate an opaque token and get information about it, the resource server must make a call to the authorization server’s introspection endpoint.

Yes, but it’s not their primary design goal. JWTs are ideal for stateless authentication. However, you can use them to manage a stateful session by using the token simply as a session identifier. The JWT would contain a session ID (`jti` or a custom claim), and the server would use this ID to look up the session data from a state store like Redis or a database. In this model, the JWT is just a secure, signed session cookie, and the server remains stateful.

A “bearer” token is a type of token where access is granted to whoever possesses (or “bears”) the token. There are no other security mechanisms tied to it; possession is proof of authorization. This is why it’s critical to protect bearer tokens (like standard JWT access tokens) from theft by always transmitting them over TLS and storing them securely.

Good to store:

• Non-sensitive, stateless information needed for authorization, like the user ID (`sub`), roles, or permissions.
• Standard claims like expiration (`exp`) and issuer (`iss`).

Avoid storing:

• Sensitive data: Personally Identifiable Information (PII) or any other sensitive data should not be in a JWS payload as it is only encoded, not encrypted.
• Large amounts of data: JWTs are sent with every API request, usually in a header. Large payloads will increase request size and latency. Keep them as small as possible.