Understanding JWT Authentication Flows: Structure, Validation, and Security Quiz

Test your knowledge of common authentication flows using JWT, including token structure, validation, secure storage, and handling expiration. This quiz helps you review key concepts and best practices for implementing and managing JWT-based authentication.

  1. JWT Structure Breakdown

    Which one of the following correctly represents the three main sections of a typical JWT as seen in the string eyJhbGciOi...e30=.eyJzdWIiOi...eyJhbGciOi...ZQ==.sDf-23bS? Choose the best answer.

    1. Header, Payload, Signature
    2. Hash, Expiration, Verification
    3. Subject, Audience, Issuer
    4. Payload, Secret, Algorithm

    Explanation: The correct answer is 'Header, Payload, Signature', which are the three parts of a JWT. 'Subject, Audience, Issuer' are common claim types inside the payload, not structural components. 'Hash, Expiration, Verification' refers to JWT features, not the sections themselves. 'Payload, Secret, Algorithm' is incorrect because secret and algorithm are not top-level sections; algorithm is in the header and secret is only used for signing.

  2. Verifying Token Authenticity

    During authentication, what is the primary method for a server to verify the authenticity of a received JWT token?

    1. By decoding the token and inspecting its payload content only
    2. By comparing the token with a list of previously issued tokens
    3. By checking the token's digital signature with a secret or public key
    4. By validating the token length is above a certain threshold

    Explanation: A server verifies a JWT's authenticity by checking its digital signature using a secret (for symmetric signing) or a public key (for asymmetric signing). Simply comparing against a token list isn't practical due to JWT's stateless nature. Payload content can be altered and does not confirm authenticity if the signature is not checked. Token length is irrelevant to verification.

  3. Token Storage Best Practices

    For a single-page web application, which of these methods is recommended for securely storing JWTs on the client side to protect them from cross-site scripting attacks?

    1. Keeping JWTs in regular JavaScript variables
    2. Saving JWTs in local storage
    3. Embedding JWTs directly in the HTML page
    4. Storing JWTs in HTTP-only cookies

    Explanation: HTTP-only cookies prevent JavaScript access, thus providing better protection against cross-site scripting attacks. Local storage is vulnerable to JavaScript access, making it less secure. Storing tokens in JavaScript variables or embedding them in HTML pages exposes them to attack and is not advised. Therefore, HTTP-only cookies are considered safer for JWT storage.

  4. Token Expiry Handling

    If a JWT used for authentication contains an 'exp' claim that indicates expiration in 15 minutes, what should a server do when it receives this token after 20 minutes?

    1. Extend the token's expiration time
    2. Reject the token as expired
    3. Automatically refresh the token without user involvement
    4. Accept the token and ignore the 'exp' claim

    Explanation: The server should reject tokens that have expired according to the 'exp' claim for security purposes. Extending the expiration without proper process breaks security principles. Ignoring the 'exp' claim undermines the reason for having expiration. Automatic token refresh should involve checking and typically requires a refresh token, not automatic renewal after expiry.

  5. Purpose of Token Signature

    In JWT, what is the main purpose of the signature section in the token?

    1. To increase the length of the token for security
    2. To store encrypted sensitive information
    3. To contain the public key for decryption
    4. To verify the integrity and authenticity of the JWT

    Explanation: The signature ensures the JWT has not been altered and confirms its authenticity. The signature does not store sensitive information nor increase token size purely for security. It does not hold public keys; it uses keys to create or verify the signature, but the key itself is not included in the token.

  6. Choosing Token Lifespan

    When configuring the expiration time for JWTs in an authentication flow, which approach is commonly preferred for improved security?

    1. Tokens that expire only when the user logs out
    2. No expiration on tokens to avoid login interruptions
    3. Short token lifespans with the use of refresh tokens
    4. Long token lifespans to reduce frequent logins

    Explanation: Short-lived tokens reduce risk if a token is compromised. A refresh token can be used to obtain new short-lived tokens, improving security. Never-expiring tokens increase vulnerability. Long expiration times are riskier if a token is stolen. Tying token expiry solely to logout does not account for stolen tokens.

  7. Decoding JWT Content

    What information can be extracted directly by decoding the payload section of a JWT without verifying the signature?

    1. Claims such as user ID, roles, and expiration
    2. The server's database password
    3. The secret key used to sign the token
    4. The private key used for signing

    Explanation: Decoding the JWT payload reveals claims like user ID, roles, and expiration, which are not encrypted by default. The secret or private key is never included in the JWT and cannot be extracted by decoding. Sensitive configuration such as database passwords should never be included in a JWT.

  8. Effect of Client-Side Modification

    If a user edits the payload of a JWT stored on their device and resends it to the server, how will a properly configured server typically respond?

    1. The server will reject the modified token after signature verification fails
    2. The server will not notice the change and accept the token
    3. The server will re-sign the token with a new signature
    4. The server will automatically update the user’s information

    Explanation: Any client-side changes to the JWT payload invalidate the signature. On validation, the server sees the mismatch and rejects the token. The server will not trust or update user information based on an unsigned or tampered token. The server never ignores signature verification, nor does it automatically re-sign tokens.

  9. Access vs. Refresh Tokens

    What is the primary role of a refresh token in a JWT-based authentication system that issues access tokens?

    1. Allow the user to obtain new access tokens after expiration
    2. Serve as a backup copy of the access token
    3. Grant direct access to protected resources without verification
    4. Provide additional user profile information to the application

    Explanation: A refresh token enables users to get a new access token once the previous one expires, improving user experience and security. It does not provide profile information or act as a backup token. Refresh tokens cannot be used directly to access protected resources; their purpose is to request new access tokens.

  10. Validating JWT Audience

    Why is it important for a server to validate the 'aud' (audience) claim in a JWT during authentication?

    1. To ensure the token was intended for this server or API
    2. To check the user's age
    3. To verify the creation time of the token
    4. To display the token’s content to all users

    Explanation: The 'aud' claim tells the server who the intended recipient of the JWT is, preventing misuse of tokens meant for other services. The aud claim does not specify user age. It is not necessary for displaying token contents or for checking creation time; both are outside the claim's intended use.