Question 1

How is a JSON Web Token (JWT) structured?

Accepted Answer

A JSON Web Token (JWT) is composed of three distinct parts separated by dots (.): Header, Payload, and Signature. (1) The Header specifies the token type and the hashing algorithm used (e.g., HS256). (2) The Payload contains the claims, which are statements about the user or session (e.g., user ID, roles, and expiration time). (3) The Signature is computed by hashing the encoded Header and Payload using a secret or private key, confirming that the token hasn't been altered.

Question 2

Can a JSON Web Token (JWT) be decrypted or read by anyone?

Accepted Answer

Yes, the standard JWT payload is merely Base64URL-encoded, not encrypted. Anyone who intercepts the token can easily decode and read its contents in plain text. Therefore, you should never store sensitive personal information, credentials, passwords, or PII (Personally Identifiable Information) inside a standard JWT payload. If encryption is required, you must use JSON Web Encryption (JWE).

Question 3

Should I store my JWT in localStorage or HttpOnly cookies?

Accepted Answer

This is a key security trade-off. (1) localStorage is vulnerable to Cross-Site Scripting (XSS) attacks; if an attacker executes malicious JS on your page, they can steal the token. (2) HttpOnly, Secure cookies protect your token from XSS because JS cannot read them, but they are vulnerable to Cross-Site Request Forgery (CSRF). Best practice is to use HttpOnly cookies combined with Anti-CSRF tokens, or maintain tokens solely in in-memory React/JS state while using a secure backend session companion.

Question 4

When should I choose symmetric HS256 over asymmetric RS256 signing?

Accepted Answer

Use HS256 (symmetric) if the signing party and verifying party are the exact same server or fully trusted microservices within the same closed network, as they must share the same secret key. Use RS256 or ES256 (asymmetric) if you are building an identity server (OAuth/OIDC) where multiple third-party clients need to verify the token. With asymmetric keys, you can publicly share your Public Key for verification while keeping the Private Key secure on your authentication server.

Question 5

How do I prevent the 'none' algorithm header bypass vulnerability?

Accepted Answer

The 'none' algorithm indicates that the token has no signature. Malicious actors can modify payloads and set the header algorithm to 'none' to bypass verification. To prevent this critical vulnerability, your server-side token validation library must be explicitly configured to reject 'none' algorithm headers in production, and enforce a strict whitelist of allowed signing algorithms (e.g., only allowing ['RS256'] or ['HS256']).

Question 6

What is a Refresh Token and how does the token renewal flow work?

Accepted Answer

Access tokens should have short lifetimes (e.g., 15 minutes) to minimize damage if stolen. To prevent forcing users to log in repeatedly, servers issue a long-lived, secure, single-use Refresh Token. When the access token expires, the client sends the refresh token to a secure token endpoint to receive a new access token and a rotated refresh token. If a refresh token is reused, the server detects token theft and invalidates the entire session.

Question 7

How do backend servers verify a JWT signature?

Accepted Answer

When a server receives a JWT, it splits the token into its three components. It reconstructs the signing input by concatenating `Base64URL(Header) + '.' + Base64URL(Payload)`. It then re-calculates the signature hash using its secret key (for HMAC) or public key (for RSA/ECDSA) and compares it strictly to the third segment (the signature) of the received token. If the signatures match and the 'exp' claim is in the future, the token is verified.

Question 8

What does 'JWT Expired' mean and how do you handle JWT token expiration errors?

Accepted Answer

When a JWT is marked as expired, it means the current Unix epoch time exceeds the value in the 'exp' (Expiration Time) claim. When your backend receives an expired token, it rejects it and returns a 401 Unauthorized status with a message like 'TokenExpiredError' or 'jwt expired'. Client applications should catch this specific error and initiate a refresh token flow to obtain a new access token seamlessly, or redirect the user to log in again if the refresh session has ended.

Question 9

How does JWT authentication work step-by-step?

Accepted Answer

JWT authentication follows four steps: (1) Authentication: The user sends credentials to the server. (2) Generation: The server authenticates the user and generates a signed JWT containing user claims. (3) Transmission & Storage: The server returns the JWT to the client, which stores it (e.g., HttpOnly cookie). (4) Access Control: For subsequent API calls, the client attaches the JWT inside the Authorization HTTP header ('Authorization: Bearer <token>'). The server verifies the signature locally and grants access instantly without database lookups.

Question 10

How do you decode and parse a JWT token programmatically?

Accepted Answer

Because Header and Payload segments are merely Base64URL-encoded, they can be decoded without verifying the signature. In JavaScript, you can parse the payload using: `JSON.parse(atob(token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/')))`. In Python, you can use PyJWT: `jwt.decode(token, options={'verify_signature': False})`. For online decoding, you can paste the token directly into our client-side [JWT Decoder](/decode) to instantly pretty-print the JSON contents.

Question 11

What does the 'Audiences (aud) in JWT are not allowed' error mean?

Accepted Answer

The 'aud' (Audience) claim specifies the intended recipients of the JWT (e.g., a specific API, service URL, or app client ID). When a server verifies a token, it checks if the token's 'aud' claim matches its own configured audience. If they do not match, the verifier throws an 'Audiences are not allowed' or 'Audience mismatch' error to prevent token substitution attacks, where a token issued for Service A is maliciously re-sent to authenticate against Service B.

Question 12

What is the 'jti' (JWT ID) claim and how does it help with JWT token invalidation?

Accepted Answer

The 'jti' claim provides a unique identifier for a specific JWT. It is primarily used to prevent 'replay attacks' (where an eavesdropper intercepting a token re-submits it) by allowing servers to store and reject already used token IDs. It also solves the stateless revocation challenge: since JWTs cannot be revoked easily before they naturally expire, you can blacklist specific 'jti' values in a fast database (like Redis) when users log out early, invalidating the token instantly.

Question 13

What does JWT stand for and what is its basic meaning?

Accepted Answer

JWT stands for JSON Web Token. It is a compact, URL-safe container standard (RFC 7519) for transmitting secure, structured information between two parties as a JSON object. Because JWTs are cryptographically signed, the recipient can instantly verify the authenticity of the sender and guarantee that the contents have not been modified or tampered with during transit.

Question 14

Which Nginx module supports the jwt_verify directive?

Accepted Answer

In commercial distributions (NGINX Plus), JWT verification is supported natively by the `ngx_http_auth_jwt_module` module using the `auth_jwt` and `auth_jwt_key_file` directives. For open-source NGINX, native JWT verification is not included. Open-source users typically implement verification by: (1) using a Lua module (`lua-resty-jwt`) via OpenResty, (2) proxying authentication requests to an external service via the `auth_request` directive, or (3) using third-party community modules like `nginx-jwt`.

JWT Knowledge Base

How is a JSON Web Token (JWT) structured?