JWT Authentication Flows: Structure, Validation, Storage, and Expiration Quiz

Test your understanding of common authentication flows using JSON Web Tokens (JWT). This quiz covers the basics of JWT structure, secure storage, validation processes, and token expiration best practices to help reinforce core concepts of modern authentication.

1. JWT Structure Basics

   Which part of a JWT contains the token's claims, such as user information and permissions?

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

   Explanation: The payload of a JWT holds the claims about the user or the data being transferred. The header contains metadata about the token, while the signature is used to verify the token's integrity. There is no 'footer' section in JWTs, making it an incorrect option.

2. Validating JWTs

   Why is it important to validate the signature of a JWT before trusting its claims?

   1. To add extra claims automatically
   2. To encrypt the token data
   3. To make the token shorter
   4. To ensure the token has not been tampered with

   Explanation: Validating the JWT signature helps ensure that the data in the token has not been altered by unauthorized parties. The signature does not make the token shorter—rather, it adds to its length. It does not encrypt the token; JWTs are only encoded, not encrypted by default. Signature validation never adds extra claims.

3. JWT Storage Options

   Which storage location is recommended for storing JWTs in a web browser to help defend against cross-site scripting (XSS) attacks?

   1. IndexedDB
   2. Local storage
   3. HTTP-only cookies
   4. Session storage

   Explanation: HTTP-only cookies cannot be accessed by client-side scripts, reducing the risk of exposure to XSS attacks. In contrast, local storage and session storage can both be accessed via JavaScript and are more vulnerable to XSS. IndexedDB also allows read access by scripts, so it is not the safest choice for sensitive tokens.

4. JWT Expiration Claims

   What is the typical purpose of the 'exp' claim in a JWT?

   1. To specify the token's signature algorithm
   2. To list the user’s permissions
   3. To define when the token should expire
   4. To encrypt the token’s contents

   Explanation: The 'exp' (expiration) claim determines the lifetime of the token, after which it becomes invalid. It does not specify the signing algorithm or encryption; the algorithm is in the header. Users' permissions are usually in the payload as custom claims, not in the 'exp' field.

5. Refreshing Expired JWTs

   If a JWT has expired, which authentication flow is typically used to obtain a new token without asking the user to log in again?

   1. Token hashing flow
   2. Implicit grant flow
   3. Refresh token flow
   4. Single sign-on flow

   Explanation: The refresh token flow allows applications to securely obtain a new access token without user intervention by using a separate refresh token. The implicit grant flow is unrelated to token renewal. Single sign-on is about using one login for multiple applications. Token hashing is a method used for securing stored tokens, not refreshing them.

6. JWT Token Tampering Check

   A server must perform which task to detect if a JWT has been altered during transmission?

   1. Verify the digital signature
   2. Re-encode the payload
   3. Store the JWT in local storage
   4. Regenerate the secret key

   Explanation: Verifying the digital signature ensures that the JWT's data has not been modified since it was issued. Re-encoding the payload would not detect tampering. Regenerating the secret key is unrelated and can break validation. Storing the JWT in local storage is a storage concern, not a detection method.

7. Public vs. Secret Tokens

   Why should the secret key used for signing JWTs never be shared with clients or included in the token?

   1. To make the token readable by anyone
   2. To prevent clients from creating valid tokens
   3. To allow cross-site requests
   4. To shorten the token length

   Explanation: Keeping the secret key hidden ensures that only trusted servers can generate valid tokens, maintaining security. Sharing the key would compromise the system by allowing clients to forge tokens. Making the token readable and cross-site requests are unrelated to key security. Token length is also unaffected by secret key exposure.

8. Insecure JWT Practices

   Which practice is considered unsafe when working with JWTs in client-side applications?

   1. Using short-lived tokens
   2. Validating tokens on every request
   3. Storing tokens in local storage
   4. Setting the 'exp' field

   Explanation: Storing tokens in local storage exposes them to JavaScript, making them vulnerable to XSS attacks. Using short-lived tokens, token validation per request, and setting expiration are recommended best practices for security.

9. JWT Structure Identification

   How many parts are separated by dots in a typical JWT, such as eyJ...eyJ...SflK?

   1. Two
   2. One
   3. Three
   4. Four

   Explanation: A standard JWT is composed of three parts: the header, the payload, and the signature, each base64-encoded and separated by dots. Two and one are too few and do not capture the signature. There are no four parts in a standard JWT structure.

10. When to Invalidate a JWT

    Which event should cause a server to reject an incoming JWT during authentication?

    1. The token uses a common algorithm
    2. The payload contains public information
    3. The 'exp' claim has expired
    4. The header uses base64 encoding

    Explanation: The 'exp' claim defines the expiration time, so expired JWTs should be rejected to maintain security. Public information in the payload is common and not grounds for invalidation. Base64 encoding in the header and use of common algorithms are standard aspects of JWTs, not security violations.