JWT stands for JSON web token is a very popular way to do user authorization in web apps today. In this blog lets talk about what JWT is and how it is used specifically in context of securing web applications. Though JWT is commonly used for authorization, the idea behind JWT is to create a standard way for two parties to communicate securely.
Authorization Strategies:
When coming to authorization we have two different authorization token mechanisms.
1. Session Token
- JSON web Token.
Why do we need authorization for a web app? The reason is since HTTP request is a stateless protocol which means every interaction in HTTP needs to contain all the information needed for that interaction, nothing is remembered from before and no state is maintained over like multiple requests.
HTTP Request Cycle:
So, let us see how this HTTP requests works for a static web application which has content accessible to everyone. For a simple static html web page client just sends the URL to the server and server responds with the HTML page. If the client needs another web page another URL will be sent, and server responds with a new HTML page as shown in below diagram. This is perfect for static web applications where there is no authorization and where each request is kind of self-contained.
For a dynamic web application where content of the web pages depends on the user things get tricky since HTTP is a stateless protocol it does not remember the previous request. For example, let us say we have a server which renders pages p1 and p2 once the client is authorized. For first request let us say client says I am user A and need web page P1, server responds with that web page. However, for the immediate request after that if the client just says I need web Page P2 server will not give P2 as it does not remember the previous request. The client must pass all the information in every request so that server knows who the user is.
To address the above scenario, web applications remember user session by using something called tokens. There are two popular ways in which this is achieved. One of them Is session tokens and the other is JSON web token.
Session Token Analogy:
Let’s consider the analogy where a customer has a request with support dept. The representative of the support dept notes down the details of the request and gives back the customer a ticket number and asks to call back after a few hours on the status of the request with this ticket number. So, the next time customer calls they need not provide all the details they have mentioned on the initial request and give the customer rep the ticket number so that they can pull all the info.
Session Token:
This is kind of what is like authorization in web applications. When a user is authenticated a sessionid is generated and stored in session log which is also passed back to the client.
For any subsequent request’s client must pass this session id so that server can perform a lookup and see who the user is. Generally, session ids are passed as cookies on http request header. This form of authenticating by using session id and cookies is the most popular mechanism for authorization which is still in practice.
Drawbacks of Session Token:
However, there are some drawbacks in this approach which is where JWT comes in the picture. This particular session based token authentication assumes that the server is a single monolithic web application which used to be the case in the past and its no longer the case with the modern web apps which use many servers sharing the load sitting behind the load balancer. So here is the issue let us say for the starting request which comes through load balancer goes to server 1 and session id gets stored inside that server. The next request which comes through say it is routed by the load balancer to server 2 which has no idea of the session id being passed since this session id is in memory of server 1.
We can address this by using a shared cache say REDIS where all servers can look up the session ids. However, this introduces a single point of failure where if the shared cache goes down all the servers do not serve the requests which is not scalable at that time.
JSON Web Token Analogy:
JWT addresses this drawback of session id approach. Now let’s consider the same example of customer and service rep. This time let’s say service rep doesn’t have any application to capture the customer request and give ticket number. So, the service rep notes down everything the customer says and gives that particular notes back to the customer and asks the customer to get that notes with details next time when the customer comes back again.
JSON Web Token:
Here we are changing the responsibilities from the server to the client. Its client’s responsibility to pass the details so that server knows who the user is. When the client first gets authenticated a json web token is passed to the client with all the details regarding the user.
This json token also has a signature so that is secure, and a malicious user cannot use the same token. The problem of security is handled here by signing the token when the client gets authenticated with the server. The json token is passed back to the client with a signature and every subsequent request to the server the signature is verified and lets the user in. Like Session Ids JWT are also sent by the cookies on the http request. Comparing session id authorization vs JWT one could say session id is a reference token for the state in the server where as JWT are value tokens which have the JSON payload of the user.
Structure of JSON web token:
Though it’s the JSON object passed back to the client. The encrypted token itself doesn’t look like JSON object. Its structured into three parts
- Header
- Payload
- Signature
JWT typically looks like the following format xxxxxx.yyyyyy.zzzzzzz
Header:
The header typically consists of two parts: the type of the token, which is JWT and the signing algorithm, which is either RSA or HMAC SHA 256.
Then this JSON object is Base 64Url encoded to form the first part of the JWT.
PayLoad:
The second part of the token is the payload which contains the claims. Claims are statements about an entity typically the user and additional data. A typical payload can look like one below:
The above payload is then Base64Url encoded to form the second part of the JSON web token,
Signature:
To create the signature part, you must take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.
For example, if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:
HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),
secret)
The signature is used to verify the message wasn’t changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.
Putting all together, the output is three Base64-URL strings separated by dots that can be easily passed in HTML and HTTP environments, while being more compact when compared to XML-based standards such as SAML. The following shows a JWT that has the previous header and payload encoded, and it is signed with a secret. Encoded JWT looks like below it is divided into three parts by a full stop delimiter.
Comments