JSON Web Token (JWT)

A JSON Web Token (JWT) is a secure way to send information between a client and a server. It is mainly used in web applications and APIs to verify users and prevent unauthorized access. A JWT is JSON data secured with a cryptographic signature.

The signing can be done using these cryptographic methods:

• HMAC (Hash-based Message Authentication Code)
• RSA or ECDSA (Asymmetric cryptographic algorithms)

JWT Structure

Here is the structure of a JWT:

A JWT consists of three parts, separated by dots (.)

Header. Payload. Signature

1. Header: Contains metadata about the token, such as the algorithm used for signing.
2. Payload: Stores the claims, i.e., data being transmitted.
3. Signature: Ensures the token's integrity and authenticity.

1. Header

The header contains metadata about the token, including the signing algorithm and token type here metadata means data about data.

{
    "alg": "HS256",
    "typ": "JWT"
}

• alg: Algorithm used for signing (e.g., HS256, RS256).
• typ: Token type, always "JWT".

Base64Url Encoded Header

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

2. Payload

The payload contains the information about the user also called as a claim and some additional information including the timestamp at which it was issued and the expiry time of the token.

{
    "userId": 123,
    "role": "admin",
    "exp": 1672531199
}

Common claim types:

• iss (Issuer): Identifies who issued the token.
• sub (Subject): Represents the user or entity the token is about.
• aud (Audience): Specifies the intended recipient.
• exp (Expiration): Defines when the token expires.
• iat (Issued At): Timestamp when the token was created.
• nbf (Not Before): Specifies when the token becomes valid.

Base64Url Encoded Payload

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNzA4MzQ1MTIzLCJleHAiOjE3MDgzNTUxMjN9

3. Signature

The signature ensures token integrity and is generated using the header, payload, and a secret key. In this example we will use HS256 algorithm to implement the Signature part

HMACSHA256(
    base64UrlEncode(header) + "." + base64UrlEncode(payload),
    secret
)

Example Signature:

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

4. Final JWT token

After all these steps the final JWT token is generated by joining the Header, Payload and Signature via a dot. It looks like as it is shown below.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNzA4MzQ1MTIzLCJleHAiOjE3MDgzNTUxMjN9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

How JWT token Works?

This diagram explains how JWT (JSON Web Token) authentication works.

Here are the key steps in simple points:

• Login Request: The user logs in through the client application (e.g., web or mobile app) by sending their credentials (username & password) to the server.
• Server Generates JWT: If the credentials are correct, the server generates a JWT token using a secret key.
• Returns JWT: The server sends the JWT back to the client application.
• Further Requests with JWT: For any subsequent requests, the client sends the JWT along with the request. The server verifies the JWT before granting access to protected resources.

Note: JWTs are primarily used for authentication and secure data exchange in web applications and APIs.

Hand-On Lab: JWT

Below is a step‑by‑step hands‑on lab on JWT authentication bypass due to an unverified signature. We are using PortSwigger to work through this hands‑on lab. Access the lab at the following link:

JWT authentication bypass via unverified signature

Step 1: Understand the Lab and Set Up Burp Suite

• In Burp Suite, ensure the Proxy module is active. You can turn intercept on initially to capture requests or rely on HTTP history.
• Click on Access the lab on portswigger

Step 2: Log In and Capture the Session Token

On the lab website, log in using the credentials wiener:peter.

• After logging in, navigate to My account.
• In Burp Suite, go to Proxy > HTTP history and find the GET /my-account request made after logging in.

Step 3: Decode and Analyze the JWT

• In Burp Suite, select the GET /my-account request in Repeater.
• Highlight the JWT in the Cookie header (e.g., session=eyJ...).
• In Burp’s Inspector panel (usually on the right), the JWT will automatically be decoded into its Header, Payload, and Signature components.

Step 4: Test Admin Access

• In Burp Repeater, modify the GET /my-account request by changing the path to /admin.
• Observe the response. You’ll likely get an error or a message indicating that only the administrator user can access the /admin endpoint.

Step 5: Modify the JWT to Impersonate Administrator

• In Burp Repeater, select the JWT in the Cookie header of the GET /admin request.
• In the Inspector panel, locate the Payload section.
• Change the sub claim from wiener to administrator

• Click Apply changes in the Inspector panel. Burp will automatically re-encode the JWT
• Send the modified GET /admin request.
• The server accepts the modified JWT and grants access to the /admin panel.

Step 6: Delete the User Carlos

• In Repeater, right-click the request and forward it to the browser. Copy the resulting link, paste it into your browser, and it will display the option to delete users.

• In the /admin response, locate the URL for deleting the user carlos. It will likely be a link like:

/admin/delete?username=carlos

• Set the request to: GET /admin/delete?username=carlos.

• The server processes the delete request, removing the user carlos.
• The lab should display a “Solved” message.

Security Considerations

When working with JWTs, keep these best practices in mind to ensure safe and reliable authentication:

• Use HTTPS: Prevent man-in-the-middle attacks by transmitting JWTs over HTTPS.
• Set Expiration Time: Prevent long-lived tokens that can be exploited.
• Use Secure Storage: Store JWTs securely (e.g., HttpOnly cookies instead of local storage).
• Verify Signature: Always validate the token's signature before trusting its content

Common Issues During Development with JWT

JWT errors often arise from mismatched details or token problems:

• JWT Rejected: The server could not verify the token. This can happen if the token has expired, the signature is invalid, or the claims do not match the expected details.
• Token Does Not Support Required Scope: The token does not include the permissions needed for the action. For example, it may allow only reading data, but the app requires write access.
• JWT Decode Failed: The token is not in the correct format or not properly encoded, so the client cannot read it.