jwt signature and validation explained

person shubham sharmafolder_openJAVA, Spring Bootlocal_offer, access_time November 17, 2024

JWT Signature and Validation Explained

JWT (JSON Web Token) is a compact, URL-safe way of representing claims to be transferred between two parties. A JWT is commonly used for authentication and authorization purposes in modern web applications, especially in the context of stateless, token-based security models.

A JWT typically consists of three parts:

  1. Header
  2. Payload
  3. Signature

These parts are encoded using Base64URL and concatenated by periods (.) to form a complete JWT string: header.payload.signature.

JWT Structure

Here is a breakdown of the structure of a JWT:

  • Header: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
  • Payload: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
  • Signature: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. JWT Header

The header typically consists of two parts:

  • alg: The signing algorithm used (e.g., HS256, RS256).
  • typ: The token type, which is JWT in this case.

For example, a header might look like this (in JSON format):

This header specifies that the token is a JWT and the algorithm used to sign the token is HMAC SHA-256 (HS256).

The header is then Base64URL-encoded to form the first part of the JWT.

2. JWT Payload

The payload contains the claims. Claims are statements about an entity (usually the user) and additional metadata. These claims can be divided into three types:

  • Registered Claims: Standard claims like iss (issuer), exp (expiration time), sub (subject), aud (audience), etc. These are recommended but not mandatory.

    Example of registered claims:

  • Public Claims: Custom claims created by the user. They must be collision-resistant.

  • Private Claims: Claims agreed upon between the parties using the JWT.

The payload is also Base64URL-encoded to form the second part of the JWT.

3. JWT Signature

The signature is used to verify that the sender of the JWT is who it says it is (authentication) and to ensure that the message wasn’t altered along the way (integrity).

To create the signature, the algorithm specified in the header is used to sign the concatenated header and payload. For example, in HMAC SHA-256, the signature is generated as follows:

  • Header and Payload are concatenated with a period (.).
  • The secret key (for HMAC algorithms) or the private key (for RSA/ECDSA) is used in the signature generation process.

In the above example:

The output is the signature, which is also Base64URL-encoded and forms the third part of the JWT.

JWT Validation Process

When the JWT is received by the server (API), the signature is validated to ensure that the token has not been tampered with and was indeed issued by the trusted source.

The validation process involves the following steps:

  1. Extract the Header and Payload:

    • Split the JWT into its three parts: Header, Payload, and Signature.

    Example:

  2. Base64URL Decode the Header and Payload:

    • Decode the header and payload from Base64URL to their original JSON format.

  3. Recreate the Signature:

    • Using the header and payload, re-create the signature using the algorithm defined in the header and the secret key or public key.

  4. Compare Signatures:

    • Compare the generated signature with the signature in the received JWT.
    • If the two match, the token is valid. If they don’t match, the token has been tampered with and is considered invalid.

  5. Check Token Claims:

    • Check claims such as:
      • Expiration (exp): The token should not be expired.
      • Issuer (iss): The token should be issued by a trusted source.
      • Audience (aud): The token should be intended for your API.
      • Subject (sub): It identifies the user or subject.
    • If any of the claims fail, the token is rejected.

Signing Algorithms in JWT

JWT supports several signing algorithms:

  1. Symmetric Algorithms:

    • Symmetric algorithms like HS256 (HMAC SHA-256) use a shared secret key between the issuer and the verifier to sign and validate the token.
    • Pros: Simple and efficient for small-scale use.
    • Cons: Both the sender and receiver need to securely share and store the secret key.

  2. Asymmetric Algorithms:

    • Asymmetric algorithms like RS256 (RSA SHA-256) and ES256 (ECDSA SHA-256) use a pair of public and private keys.
      • The token is signed using the private key (only known to the issuer).
      • The token is verified using the corresponding public key (distributed and available to anyone).
    • Pros: More secure since the public key can be freely distributed without compromising the private key.
    • Cons: Slightly more complex setup with the need for key-pair generation and distribution.

How JWT Signature Enhances Security

The JWT signature ensures:

  1. Integrity: If someone tries to tamper with the payload (e.g., modifying claims like admin: false to admin: true), the signature will not match, and the token will be rejected.
  2. Authentication: The signature proves that the token was issued by a trusted source (since only the issuer has access to the secret key or private key used to sign the token).
  3. Stateless Authentication: The server does not need to store any session data. The JWT itself contains the necessary information for authentication and validation, making it ideal for distributed systems and microservices.

Example JWT Validation Flow in Spring Boot

Here’s how the validation process typically works in a Spring Boot application with JWT:

  1. User Requests Access:

    • The user logs in with their credentials (username and password).

  2. JWT Issuance:

    • If the login is successful, the server generates a JWT, signs it using a secret key (HS256) or private key (RS256), and returns it to the user.

  3. Client Stores JWT:

    • The client (browser/mobile app) stores the JWT (typically in localStorage or cookies) and includes it in the Authorization header (Bearer <token>) with each subsequent request to the server.

  4. Server Validates JWT:

    • For every incoming request, the server extracts the JWT from the Authorization header.
    • The server decodes the JWT, verifies the signature, and checks the claims (expiration, issuer, audience, etc.).
    • If the token is valid, the request proceeds, and the server can identify the user based on the token’s claims.
    • If the token is invalid or expired, the server returns an HTTP 401 Unauthorized response.

Conclusion

  • JWT Signature: Ensures that the token hasn’t been altered (integrity) and is issued by a trusted entity (authentication).
  • JWT Validation: Involves checking the signature and

the claims (e.g., expiration, audience) to determine if the token is valid.

  • Security: JWT tokens are secure and efficient for stateless authentication but should always be transmitted over HTTPS to prevent interception.

By validating the JWT signature and claims, applications can securely authenticate and authorize users in a stateless manner, which is highly beneficial in distributed systems like microservices architectures.

warningComments are closed.