What is the purpose of JWT(JAWT)?
JWT is a standard which helps the services(typically backend micro-services) to recognise a user and provide them the access to the resources which they are interested in.
What is the need of JWT?
Traditionally, we had static web-pages. So, whenever we are interested in a resource we will send the request to the server and the server will fetch us the corresponding static page mapped with that url in the request.
Nowadays almost all the websites fetches the data dynamically from the server based on the user who is making the request. We already know that HTTP is a stateless protocol, which means it wont remember the details which was sent in the previous request. So, the user has to identify themselves each time when they want to access resource from the server which is a headache!
Also, it is not recommended to send the sensitive information like password along with the username to recognise yourselves in each request. So, we need a mechanism to identify ourselves to the server once the authentication is done for the first time.
Session Tokens to rescue!
Before JWT, We used something called session tokens to identify the user. So, whenever the user logs themselves in for the first time, the server will create an id for that user and stores the information like a key-value(id: user-details) pair in the cache and sends the id to the user in the response-header. The browser will store that id from the response-header in the cookie/local-storage. For the subsequent requests, the browser will send that id in the request header to the server to identify themselves.
This approach worked fine for long-time. But there is a drawback with this approach. In these days, we tend to create multiple instances of single service and we have a load-balancer to route our requests to any of the available service at that point of time.
Not clear? We’ll discuss that in depth.
Here the user makes a login call to the server, the load-balancer routes the request to the 1st instance of that service. The server then stores the information of the user in the session-log and sends the session-id in the response header. Now, in the subsequent request if the load-balancer routes the request to the 2nd instance of that service, we don’t have the session-log to perform the lookup and identify the user.
We had an alternative to the above approach as well, to have a common cache for all the microservice to maintain the session information like the below:
It also comes with a drawback, we have a single point of failure. If the shared-cache goes down then its a problem. Not great right!
How JWT solves the problem?
Instead of storing the user information in the server, we can create a JSON payload with the required user information and send it back to the browser.
Isn’t that an overhead to send the whole JSON payload in the requests and responses of subsequent request? and how it is secured?
Well, the answer is, we will encode the JSON payload to make it somewhat convenient to send it in the request and responses. We will sign the token to assure the security.
Structure is JWT:
This is how a typical JWT will look like, It has 3 parts:
- Header
- Payload
- Signature
Header:
Header will hold the JSON payload with details like what algorithm we used to sign the token and the type of the token.
Payload:
Payload will hold the JSON payload of the user information and the expiration time of the token etc…
Signature:
This part is the signature of the token, it is calculated by the algorithm like RS256/HS256.
How JWT is validated in the server side to ensure its correctness?
When we create a JWT token, we will encode the header and payload JSON using the Base64 encode. The signature is calculated by encoding the header and payload along with the secret-key. This secret-key is only known to the server.
When we get the JWT token for the subsequent request to the server, we will validate it by decoding the header, payload along with that we will use the secret-key(which is only known to our server) to see whether the incoming token’s signature matches with the signature which we calculate in the server-side. In this way, even if the user tampers the token, the server validation will fail when it calculates the signature while validating by decoding the token and calculating the signature.
Hope you learned something out of this!
