JWT Insights: Structure, Signatures, and Security Fundamentals Quiz

Explore key concepts of JSON Web Tokens (JWT), including their structural components, signature mechanisms, and common security risks. This quiz is designed to reinforce foundational knowledge and best practices surrounding JWT usage and vulnerabilities.

1. JWT Basic Structure

   What are the three main parts of a JWT, traditionally separated by periods in the token string?

   1. Payload, Footer, Signature
   2. Header, Claim, Footer
   3. Header, Payload, Signature
   4. Header, Signature, Password

   Explanation: The three core sections of a JWT are the Header, Payload, and Signature, each separated by a period. The Header specifies metadata, the Payload contains claims, and the Signature ensures integrity. 'Header, Signature, Password' is incorrect as password is not a JWT component. 'Payload, Footer, Signature' misnames 'Footer' which does not exist. The option 'Header, Claim, Footer' is incorrect; 'Claim' is part of the payload and there's no 'Footer'.

2. JWT Encoding

   Which encoding format is used for each part of a JWT before concatenation?

   1. Hexadecimal
   2. Base64Url
   3. Base32
   4. UTF-16

   Explanation: Each section of a JWT (Header, Payload, Signature) is encoded using Base64Url, which is a URL-safe variant of Base64. Hexadecimal and Base32 are different encoding schemes not used in this context. UTF-16 is a character encoding for Unicode; it is not used for JWT serialization.

3. Signature Purpose

   What is the primary purpose of the signature part in a JWT?

   1. To verify the sender’s authenticity and ensure token integrity
   2. To generate a unique token ID
   3. To encrypt the payload for privacy
   4. To compress the token size

   Explanation: The signature ensures the JWT has not been altered after issuance and verifies the identity of the issuer or sender. It does not encrypt the payload; JWTs are typically not encrypted but signed. Generating a unique token ID is done through claims like 'jti,' not the signature. Compression is a separate concern and unrelated to the signature.

4. Typical JWT Algorithm

   In a JWT header, what does the 'alg' field represent (e.g., 'alg': 'HS256')?

   1. The algorithm used for the signature
   2. The algorithm for payload encryption
   3. The algorithm for token expiration
   4. The algorithm for payload decoding

   Explanation: The 'alg' field indicates the signature algorithm applied, such as HS256 for HMAC SHA-256. It does not describe an algorithm for encrypting the payload—JWTs are not encrypted by default. Token expiration is configured with other claims such as 'exp.' Payload decoding is typically handled via Base64Url, not specified in the 'alg' field.

5. JWT Claims

   What is the purpose of claims like 'exp' or 'iat' in the JWT payload?

   1. They encrypt the payload
   2. They provide metadata about the token, such as expiration and issued time
   3. They describe the encoding algorithm
   4. They contain the signature

   Explanation: 'exp' and 'iat' are claims in the payload that represent expiration time and issued-at time, respectively, which are pieces of metadata about the token’s validity. They do not contain the signature—that is in a separate section. Describing the encoding algorithm is done in the header, not the payload. JWT payloads are not inherently encrypted.

6. Algorithm None Vulnerability

   What is a security risk when a JWT implementation allows the use of the 'none' algorithm for the 'alg' field in the header?

   1. It generates duplicate token identifiers
   2. It disables Base64Url encoding
   3. Attackers can bypass signature verification and forge tokens
   4. It increases the size of the JWT

   Explanation: If the 'none' algorithm is accepted, signature verification can be skipped, allowing attackers to alter the payload and forge tokens without detection. The size of the JWT or the encoding method are not affected by this setting. Duplicate token identifiers are unrelated to the signature algorithm.

7. Token Expiry

   What happens if the 'exp' claim in a JWT payload is set to a time in the past?

   1. The token is automatically refreshed
   2. The token will be validated normally
   3. The signature is recalculated
   4. The token is considered expired and should be rejected

   Explanation: A JWT with an 'exp' (expiration) time in the past is considered expired and should not be accepted by the recipient for security. Normal validation is not performed for expired tokens. Automatic token refresh is not standard; a separate refresh token mechanism is used. The signature does not get recalculated due to expiration.

8. Signing Methods

   Which of the following is a common symmetric algorithm for signing JWTs?

   1. HS256
   2. RS256
   3. DSA-256
   4. ES256

   Explanation: HS256 is a symmetric algorithm based on HMAC and SHA-256, where the same key is used for both signing and verification. RS256 and ES256 are asymmetric algorithms utilizing public and private keys. 'DSA-256' is not a standard or widely used JWT signing algorithm.

9. Public Exposure Risk

   What is a major risk if you accidentally expose the secret key used to sign JWTs?

   1. Attackers can decode the token payload
   2. Attackers can create valid tokens and impersonate users
   3. Tokens will no longer be Base64Url encoded
   4. It will automatically change the expiration time

   Explanation: If a secret key is leaked, attackers can generate new signed tokens, allowing them to impersonate authorized users. Decoding the payload is possible without the key since it's just Base64Url. The key exposure does not affect the encoding method or modify expiration times.

10. JWT in Browser Storage

    Why is storing JWTs in browser localStorage considered a security risk?

    1. They can be accessed by malicious scripts via cross-site scripting (XSS) attacks
    2. Headers cannot be read anymore
    3. Tokens become truncated automatically
    4. The payload gets automatically overwritten

    Explanation: LocalStorage is accessible through JavaScript, so if a website is vulnerable to XSS, malicious scripts can steal stored JWTs. Tokens are not truncated automatically by being stored this way. JWT headers and payloads remain accessible as usual. Overwriting the payload does not occur by default in browser storage.