Internal Working Structure of JWT

In the modern era of web development, secure and efficient data exchange is a cornerstone of building robust applications. JSON Web Token (JWT) has become a widely adopted standard for securely transmitting information between parties. Its compact, self-contained, and stateless nature makes it a preferred choice for authentication and authorization in web applications, APIs, and microservices. But what exactly is JWT, and how does it work internally? Let’s explore its structure and internal mechanisms.

What is JWT?

​JWT (JSON Web Token) is an open standard (RFC 7519) that defines a compact and self-contained way to securely transmit information as a JSON object. It is primarily used for:

1. Authentication: Verifying the identity of a user or system.
2. Authorization: Granting access to resources based on the user's identity.

A JWT is essentially a string that consists of three parts:

1. Header
2. Payload
3. Signature

These parts are separated by dots (.), forming a structure like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Let’s break down each part to understand how JWT works internally.

1. Header

The header contains metadata about the token, such as the type of token and the algorithm used for signing. It is a JSON object that is Base64Url-encoded.

Example Header:

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

​

• alg: Specifies the algorithm used to sign the token. Common algorithms include:
  
  • HS256 (HMAC with SHA-256)
  • RS256 (RSA with SHA-256)
• typ: Indicates the type of token, which is always JWT.

After Base64Url encoding, the header becomes:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 

2. Payload

The payload contains the claims, which are statements about an entity (usually the user) and additional data. Claims are also represented as a JSON object and are Base64Url-encoded.

Example Payload:

{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}

​

• sub: Subject of the token (e.g., user ID).
• name: Name of the user.
• iat: Issued At, which is the timestamp when the token was issued

There are three types of claims:

1. Registered Claims: Predefined claims like iss (issuer), exp (expiration time), sub (subject), and aud (audience).
2. Public Claims: Custom claims that are agreed upon by both parties.
3. Private Claims: Custom claims used internally by the application.

After Base64Url encoding, the payload becomes:

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

3. Signature

​The signature is used to verify the authenticity of the token and ensure that it hasn’t been tampered with. It is created by taking the encoded header, the encoded payload, and a secret key, and then applying the specified algorithm.

Formula for Generating the Signature:

​HMACSHA256 (

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

)

For example, if the secret key is mysecretkey, the signature might look like this:

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Complete JWT

​When we combine the encoded header, payload, and signature, separated by dots (.), we get the complete JWT:​

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

How JWT Works Internally

​

• Token Creation:
  
  • The server generates a JWT after the user successfully authenticates.
  • The header and payload are created as JSON objects, encoded using Base64Url, and signed with a secret key.
• Token Transmission:
  • The JWT is sent to the client (e.g., browser or mobile app) and stored, typically in local storage, session storage, or a cookie.
• Token Usage:
  • The client includes the JWT in the Authorization header of HTTP requests to access protected resources:  Authorization: Bearer <JWT>
• Token Verification:
  • The server receives the JWT and splits it into its three parts: header, payload, and signature.
  • It verifies the signature using the secret key or public key (in case of asymmetric algorithms like RS256).
  • If the signature is valid, the server trusts the claims in the payload and processes the request.

​A Bearer Token is a type of access token that is used in authentication and authorization systems to grant access to protected resources. The term "bearer" implies that whoever possesses the token (the "bearer") is authorized to access the associated resources. It is commonly used in modern web applications, APIs, and OAuth 2.0-based systems.​

Advantages of JWT

1. Compact: The token is small and can be easily transmitted via URLs, headers, or cookies.
2. Self-contained: All the information needed for authentication is included in the token, reducing the need for server-side storage.
3. Secure: The signature ensures the integrity of the token, and sensitive data can be encrypted if needed.
4. Stateless: JWTs enable stateless authentication, which is ideal for distributed systems and microservices.

Limitations of JWT

1. No Built-in Revocation: Once issued, a JWT cannot be revoked unless additional mechanisms like a blacklist are implemented.
2. Size: JWTs can become large if the payload contains too much data.
3. Expiration Management: Proper handling of token expiration is crucial to prevent unauthorized access.

Best Practices for Using JWT

1. Use Short Expiration Times: Set a short expiration time (exp) to minimize the risk of token misuse.
2. Use HTTPS: Always transmit JWTs over HTTPS to prevent interception.
3. Avoid Storing Sensitive Data: Do not store sensitive information (e.g., passwords) in the payload.
4. Implement Token Revocation: Use a blacklist or other mechanisms to revoke tokens when necessary.
5. Use Strong Secrets: Use a strong, random secret key for signing tokens.