What is JWT?

JWT stands for JSON Web Token. It defines a mechanism that we can transmit information securely between parties. A JWT is relatively small in size which enables us to send it through HTTP header or post parameter etc.

Here is an example for JWT. It is an encoded string(Not encrypted).

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

One of the most common use cases of JWT is for authorization. Authorization is a mechanism used to verify a user that sends requests to the server is the same user authenticated. Only if the user is authenticated, he is allowed to access the system.

Older times this was done by keeping a session in the server. Once the user logs in to the system, the server generates a session Id and sends it to the browser to save it in a browser cookie. Every time client makes a request to the server, it sends a session Id to the server and the server will verify if the user is authorized or not. But if we use the same server to serve a native mobile app, they do not have cookies. That’s why JWT comes into the picture.

How JWT Works in authorization?

Once the user logged in to the system, it will create a JWT and send it back to the browser. If it is a web application we can store it in local storage for instance. When every request sends to the server it will verify the token and make sure the user is authorized to do the particular action. Important thing is, here we are not keeping anything on the server side like in session-based authorization. JWT contains every information about the user and can be used to verify user. If the token has been tampered with, the server will invalidate it.

What is inside JWT?

There are 3 parts in a JSON Web Token.

1. Header
2. Payload
3. Signature

JWT is on left-hand side. In decoded version, we can see the header, payload, and signature.

Header:

• alg is the hashing algorithm that generates the signature. typ indicates the token type which is JWT here.

Payload

• Payload is the actual data we need to store in the token. sub will most probably be the id of the user you want to authorize. Other than that, It has some common fields also such as iss, iat and exp.
• iss: (Issuer) Who issues the JWT.
• iat: (Issued at) Issued time of the token.
• exp: (Expiration time) when JWT expires.
• It is best practice to have an expiration on token otherwise if someone gets your token they can use it forever to access the system by authorizing themselves as you.

Signature

• Actually, this is the part that verifies the user has not been messed with the token. It will take the header section and payload section. Then it encodes them with the algorithm mentioned in the header using a secret key provided by us and will combine them together. Let’s take a look at how it is done.

const encodedHeader = base64urlEncode(header);
const encodedPayload = base64urlEncode(payload);
const data = encodedHeader + "." + encodedPayload; 
const hashedData = HS256(data, <secret_key>);
const signature = base64urlEncode(hashedData);
const JWT = encodedHeader + "." + encodedPayload + "." + signature;

First, header and payload are encoded. Then combined encoded header and payload is hashed using a hashing algorithm (Here it is HS256)using some secret key. And Then hashed data will be encoded (signature).

Now we have 3 separate encoded parts encodedHeader, encodedPayload and signature. Combining these 3 separated by dots is nothing but a JWT.

There is a platform we can play around with this. Let’s try that.

In payload, ‘Frodo Baggins’ has been provided as the username. The secret key is ‘shhh’. What will happen if someone changes the JWT? This is what happens when the letter ‘e’ is removed, followed by the first period of the token.

Since payload section of the token has been changed, signature will be changed. Because signature is hashed data of both header and payload and no longer similar to the last blue portion of the JWT. Then it will be identified as an invalid signature. So, if it is invalid we know the token has been tampered with. That is why actually we can store the user information in the client. Anyway, if a user has your secret key then again he will be able to create a valid token. Therefore in real cases, the secret key must be hard to guess and safely stored in your server to make it inaccessible to others.