What is JWT and Why does it matter ? Authorization Tokens Part 2

The story starts with a problem. The problem that occurs with Session Tokens. We discussed in Part1. Give that a 4 minute read before this one.

The Dawn Of JWT

You see all the problems with Session Tokens started because the Session information, Authoriazation information or the Credentials all are saved in the server side. To solve that we introduced different ideas or technologies but none really worked perfectly. What if we remove the cause of the problem ? I mean let’s not save anything on the server side if that’s causing it all. Well, this switched proposal actually gave birth to JWT (JSON Web Tokens).

How the heck does JWT work ?

Let’s get back to the Bank Analogy that we have been using. Suppose you send a request to login to your Bank Website. You provided ID Pass and necessary information for that. You logged in. This time the Bank Server checks your information, validates them, authorizes you and instead of saving the interaction or credentials in their side, it actually writes them in a JSON object and hands the object back to your browser. This JSON body is the JWT or JSON Web Token. Just like the Session ID/Session Token, your browser saves the JSON Web Token and includes that in every next request that you send to the server.

This JSON body or the JSON Web Token works as a token because it tells the server that this is the right person, here are the details of this person. Notice that previously with Session Token/Session Id, the server used to save the information about the interaction or about is on it’s side and the Token was used like a reference to that Server memory. The token told the server where to look for the information. But this time JWT is not a referrer, it is the information ! That’s why every time we send the whole information about us with every request.

Problems with JWT : Yes you read right :)

Although it seems to solve the “saving everything server side” issue, JWT has it’s own problem. For example :

Problem -> Trust Issue : The JSON body does not contain any sensitive information like credentials. It just contains who we are and some of our previous interaction. We can easily change our username to someone else or change the interaction data in the JSON body, right ? Then How does the server believe us that we had not tampered with the JSON body and are claiming to be Brad Pitt even though we are not ?

Solution -> Sign the damn thing : To solve the trust issue, the server does not create a JSON Web Token randomly. It actually signs the Token after creating it and then hands it back to the client browser. We will discuss about the signing process shortly. But what this sign does is make the token impossible to tamper. If we change any data inside the JSON body, the signature will change and thus if we send the Token back with a new request, the server will decline that request because of the signature mismatch.

STRUCTURE & CREATION

Let’s now discuss how a JSON Web Token looks like. In the process we will understand how the signature makes the Token impossible to tamper.

Example JWT

Well, it does not look like a JSON Body right ? JWT does not carry JSON body in cleartext. The server first creates the JSON body with Header and Signature, encodes it in base64 encoding and then transfer it to the client. After all this, the token looks like the picture.

There are 3 main parts of a JWT token. You can notice that the picture has 3 different colored text and they are separated by dots. Let me show you the decoded value of the token, the three parts will be much clearer then.

Payload : First look at the middle portion of the token. It’s called payload. This is the actual JSON body or JSON object that has your information. This information tells the server that this is the right person. Notice that the payload does not have any password or credentials. That’s because the first time you logged in with your credentials, the server authenticated you. Then, for future usage, the server created this JWT for you and signed it then handed it over to you. This JWT token is not for authentication, it’s a written document that the server knows you and you have been authenticated once.

Header : The beginning of the JWT is called the Header. It holds which type of Algorithm has been used to sign the token. This part is also base64 encoded .

Signature : This is the special part that the server did to the token before handing it over to us. It’s important because if we try to tamper with the data, this value changes. And if this value changes, the server does not accept our token. To create this part, the server takes base64 encoded Header and base64 encoded Payload , separates them with a dot and then applies a secret key on them. Finally it wraps up the whole thing with the algorithm mentioned in the Header portion.

Finally the server takes all 3 parts, separates them with a dot and hands the token over to our browser. Whenever we send the next requests to the server, our browser sends this token as Cookie Header. The server gets our token, decodes the Header and Payload portion, calculates the signature with secret key and compares the signature part of our send Token and it’s calculated signature. If they match, the server knows no one has tampered with the Token, so it goes ahead. If the signature mismatches, the server gets suspicious and doesn’t let us in.

Question 1 : If the Header which tells what kind of algorithm we need to generate the signature and the Payload which is the actual information is there, can we not take them & create a signature ?

Ans : The answer is no. We can never create a signature identical to the server’s signature. Because while creating the Signature, server used a secret key , even though we have all the other information, we don’t have the secret key. So we can’t create the same signature.

Question 2 : What happens if we change the Payload Data ?

Ans : Remember in third step, while creating the signature, the server actually took both the Payload Data and Header Data and then applied algorithm on them ? That saves the day. If we change or tamper with the Payload data, whenever we send back the Token and the server calculates the signature again to verify us, it get’s a different signature value while calculating. So it does not let us in.

Question 3 : What happens if we get someone’s JWT ?

Ans : As we have discussed that the server only checks if the signature matches, it does not check who is sending the Token. That means if we can send someone’s else’s Token to the server, it will let us in as that person.

The Difference Between JWT & Session Tokens

Session Token is like a referrer which points to the memory place of the server where our information is saved. JWT literally contains the information in it.