As we know, HTTP is a stateless protocol where each request is treated as an independent request. For rendering static web page, this could still be fine, but what if the web application needs to track a user across multiple requests.That is where Session and state management came to the picture. The server will authenticate the user and if it’s a valid request, the server will save the session id and return the same to the client. The client can pass this session-id for any subsequent request. The server will check for the session id and will process the request for the client.
With server-side session management, scalability can be a challenge, say we have a load-balanced scenario, the user sends a session id in the request which goes to a different server which knows nothing about the session causing failure. Now we can always save the session id in the database which will bring its overhead.
This is where JWT – JSON Web Token comes to rescue that comply with the stateless nature of the HTTP.
JSON is an open standard RFC 7519, that defines a compact and self-contained method for securely transferring information between parties.
The format of JSON Web Token
header.payload.signature
payload is the part of transmitted data that is the actual intended message in computing.
The header will typically contain
- typ – the type of media, JWT in this case.
- alg – the algorithm used for signing and/or decryption the JWT
The payload contains information about the client or set of claims. There are seven registered (public) claims and we can define private (custom) claims also.
| iss | issuer | The party that issued the JWT |
| sub | subject | The party that this JWT carries information |
| aud | audience | Intended recipient |
| exp | expiration | Exact moment from which the JWT is considered invalid in ‘seconds since Epoch’ format |
| nbf | from not before | Exact moment from which the JWT is considered valid. |
| Iat | Issued at time | Time when the JWT was issued |
| jti | JWT ID | Unique identifier for this JWT |
The third part signature is computed as follows:
Header and Payload are encoded using Base64url encoding and are concatenated with a period separator.
This is then run through the algorithm specified in the header.
HS256(secret, base64URLEncoding(header) + “.” + base64URLEncoding(payload))
The signature is also encoded using Base64urlEncoding
Finally, the token will be
token= base64urlEncoding(header) + ‘.’ + base64urlEncoding(payload) + ‘.’ + base64urlEncoding(signature)
We can encode or decode JWTs at
Here changing the Payload will change the JWT String.
The flow will look something like below
Get the free comprehensive guide on JWT
Hope it helps..
Nishant Rana's Weblog 
One thought on “JWT – JSON Web Token – Introduction”