JWT Essentials for Single Page Application Security Quiz

Explore key concepts and best practices for using JSON Web Tokens (JWT) in securing Single Page Applications (SPAs), with a focus on token handling, storage, and common pitfalls in token-based authentication. Perfect for understanding vulnerabilities and strengthening SPA security in modern web development.

1. JWT Structure and Claims

   Which component of a JWT contains the user’s data, such as roles or permissions, in a Single Page Application example?

   1. Header
   2. Payload
   3. Signature
   4. Footer

   Explanation: The payload component of a JWT holds the claims, which can include information about the user such as roles or permissions. The header contains metadata about the token, not user data. The signature is used to verify the token’s integrity, not to store claims. 'Footer' is not a standard part of the JWT structure, making it an incorrect option.

2. JWT Storage in SPAs

   What is a key security risk when storing JWTs in localStorage within a Single Page Application?

   1. Susceptibility to brute force attacks
   2. Increased network latency
   3. Vulnerability to cross-site scripting (XSS)
   4. Loss of token after browser refresh

   Explanation: Storing JWTs in localStorage puts them at risk of XSS attacks since malicious scripts can access the tokens. Brute force attacks are related to weak secret keys rather than storage location. Network latency is not affected by where the token is stored. Tokens in localStorage persist after a browser refresh, so loss of token is not accurate.

3. Token Expiration and Refresh Strategies

   When using short-lived JWTs in SPAs, which approach best maintains a seamless user experience without compromising security?

   1. Disable token expiration
   2. Automatically renew tokens with silent refresh
   3. Embed user password inside the token
   4. Reject requests after token expiration with no renewal

   Explanation: Silent token refresh allows applications to renew tokens behind the scenes, maintaining both security and usability. Disabling expiration is insecure because tokens could be used indefinitely if leaked. Embedding user passwords inside tokens is highly insecure and never recommended. Rejecting requests without renewal would forcibly log users out, disrupting the user experience.

4. Audience Validation in JWTs

   In the context of a SPA, why should the 'aud' (audience) claim in a JWT be checked by the backend?

   1. To encrypt the token payload
   2. To ensure the token is intended for this API
   3. To reduce the size of the JWT
   4. To increase signature complexity

   Explanation: Validating the audience claim ensures that the token is meant for the intended backend or API, preventing misuse. The 'aud' claim does not encrypt the payload and has no effect on token size. Checking the audience is unrelated to signature complexity, whose purpose is verifying token integrity.

5. Best Practices for Token Revocation

   What is a common method for revoking JWTs in SPAs, given that JWTs are stateless and cannot be directly invalidated?

   1. Implementing a token blacklist on the server
   2. Changing the JWT header format
   3. Storing JWTs in cookies only
   4. Reducing the payload content

   Explanation: A server-side blacklist allows selective invalidation of tokens before their expiration, addressing the stateless nature of JWTs. Changing the header format does not affect revocation and may break compatibility. Storing JWTs in cookies affects storage method, not revocation. Reducing payload content has no impact on the ability to revoke tokens.