JWT Signature Verification & Security Checks Quiz Quiz

Assess your understanding of JWT signature verification and essential security checks in token-based authentication systems. This quiz covers signing algorithms, signature validation, vulnerabilities, and best practices for robust JWT security.

  1. Importance of Signature Verification

    In the context of JWT signature verification, why is it crucial for an application to always verify the token’s signature before trusting its claims in an API scenario?

    1. To ensure that the token was indeed issued by a trusted authority and its contents have not been tampered with
    2. To compress token size and maintain faster network transfer
    3. So that tokens will automatically expire after a fixed time period
    4. To generate random tokens for every user session

    Explanation: Verifying the JWT signature guarantees that a trusted party issued the token and that its contents remain unchanged, which is essential for security. Compressing token size is unrelated to signature verification. Token expiration is managed by claims, not by signature checking itself. Generating random tokens is also not a function of signature verification, but of token creation.

  2. Algorithm Confusion Vulnerability

    Which of the following best describes the 'algorithm confusion' vulnerability when validating JWTs in an authentication server?

    1. The server accepts a token with the 'alg' value set to 'none', allowing attackers to bypass signature checks
    2. The server refuses tokens with any HMAC algorithm specified
    3. Token expiry limits are ignored if the algorithm is not recognized
    4. The server always uses elliptic curve encryption for verification regardless of the 'alg' value

    Explanation: Algorithm confusion occurs when a server inadvertently accepts unsigned tokens by permitting 'alg: none', allowing attackers to bypass authentication. Simply refusing HMAC algorithms is not the core issue. Ignoring expiry or always using elliptic curve verification does not directly represent this vulnerability; those are unrelated misconfigurations.

  3. Key Management in JWT Validation

    When validating JWTs signed with asymmetric keys (for example, RS256), what is the most secure method for the server to obtain the public key needed for signature verification?

    1. The server should securely retrieve the public key from a trusted and authenticated endpoint or configuration
    2. The server should generate a new public key with every incoming request
    3. The server can extract the public key directly from the JWT payload
    4. Any available public key on the server can be used for all tokens

    Explanation: Best practice is for the server to obtain and manage the public key securely from a trusted source, ensuring authenticity. Generating a new key on every request breaks the trust model and is unnecessary. Allowing the JWT payload to provide the public key lets an attacker specify their own verification key, defeating security. Using any public key on the server ignores proper key management and may result in validation failures or vulnerabilities.

  4. Signature Validation Failure

    If an application receives a JWT and detects that its signature is invalid during verification, what should it do next for proper security?

    1. Reject the token and deny access to the corresponding request
    2. Strip the signature and use the claims portion only
    3. Re-sign the token with the server’s own key
    4. Update the JWT algorithm to HMAC automatically

    Explanation: An invalid JWT signature means the token cannot be trusted; the correct action is to reject it and deny access. Stripping the signature and trusting the payload defeats the purpose of signatures. Re-signing the token is insecure since the original authenticity is lost. Automatically changing the algorithm does not fix or validate the original token.

  5. Best Practices for JWT Security Checks

    Which of the following is considered a best practice for performing robust security checks on JWTs in production environments?

    1. Validate both the signature and all standard claims, such as expiration and issuer
    2. Store the JWT payload unencrypted in client-side session storage only
    3. Allow missing 'iat' and 'exp' claims to support more flexibility
    4. Accept tokens from any source as long as the structure matches JWT format

    Explanation: Best practice is to validate both the cryptographic signature and standard claims to ensure the token is genuine and not expired. Storing payloads unencrypted client-side can expose sensitive information. Omitting claims like 'iat' and 'exp' can lead to replay or abuse. Accepting tokens solely based on structure ignores authentication and verification requirements.