JWT

JSON Web Token - (JWT)

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims (information) to be transferred between two parties. It is a security mechanism used primarily for authentication and authorization in web applications, allowing a server to verify a user's identity and permissions securely. Since a JWT is digitally signed using a secret or a public/private key pair, its contents can be verified and trusted. JWTs can be used for stateful or stateless sessions, commonly replacing traditional server-side session management.

JWT Structure

A JWT is a string composed of three distinct parts, separated by dots (.), typically looking like this: header.payload.signature.

1. Header

The header contains metadata about the token itself, specifically the type of token and the hashing algorithm used for the signature.

Algorithm: (alg)

This specifies the algorithm used to sign the token. The server will use this algorithm, along with the secret, to generate and verify the signature.

Type: (typ)

This specifies the type of token, which is usually JWT

Example:

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

2. Pyload

The payload contains the claims—statements about an entity (like a user) and additional data. It holds the actual information being securely transmitted.

claim:

A claim is a piece of information stored in the JWT payload. Claims are essentially key-value pairs that provide information about the token's subject (the user), the issuer, or other necessary application-specific data.

1. Registered Claims: Pre-defined, standardized claims (e.g., iss for issuer, exp for expiration time, sub for subject).
2. Public Claims: Claims defined by people using JWTs, but designed to be collision-resistant.
3. Private Claims: Custom claims created to share information between parties who agree on their meaning (e.g., a user's role).

payload section

The Payload section is the JSON object that holds all these claims. After the claims are added, the JSON object is Base64URL-encoded to create the middle part of the JWT string. It is important to remember that the payload is only encoded, not encrypted, meaning sensitive information should not be placed here.

{
  "sub": "user_id_42",        // Subject (Registered Claim)
  "name": "Jane User",        // Public Claim

  "exp": 1731940799           // Expiration t
  "role": "administrator",    // Private Clai
mime (Registered Claim)
}

Example:

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

3. Signature

The signature is used to verify that the sender of the JWT is who they claim to be and to ensure the token hasn't been tampered with. It is created by taking the encoded header, the encoded payload, and a secret (known only to the server) and running them through the specified algorithm (e.g., HMAC-SHA256).

Example:

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

JWT Workflow:

JWT (JSON Web Token) is an open standard used to securely transmit information between two parties in a stateless manner, meaning the server does not need to store user sessions. A JWT is made of three parts: the Header, Payload, and Signature. The header contains metadata, such as the token type (JWT) and the signing algorithm (like HS256). The payload carries the actual user data and claims, for example the user ID, email, expiration time (exp), and subject (sub). The signature ensures the token’s integrity; it is created by encoding the header and payload using Base64URL and then signing them with a secret key (in symmetric signing) or with a private key (in asymmetric signing). This structure ensures that if any part of the token is tampered with, the server will immediately detect it during verification.

The authentication workflow begins when the client initiates a login request by sending a username and password to the server. The server validates these credentials against the database. Once the credentials are confirmed, the server creates a JWT by assembling the header and payload, then generating a cryptographic signature. The server returns this newly created JWT to the client, which then stores it—typically in localStorage, sessionStorage, or a secure HTTP-only cookie. After this point, the client includes the token in the Authorization: Bearer token header for every protected request. When the server receives this request, it verifies the token by recalculating the signature and comparing it with the incoming signature to ensure the token hasn’t been modified. It then checks claims like expiration time to ensure the token is still valid. If both checks pass, the server processes the request and returns the requested data. This entire process enables stateless authentication, since the server relies solely on the token and does not maintain session data.

Finally, the signing mechanism shown in the infographic highlights two approaches: symmetric signatures, where the same secret key is used for both signing and verification, and asymmetric signatures, where the server signs the token using a private key and verifies it using a public key. Both methods guarantee token integrity, but asymmetric signing is more secure for distributed systems. In summary, JWT enables a simple but powerful workflow: the client logs in, receives a signed token, stores it, and sends it with every request, while the server verifies the token each time without storing session state.