Everything about JWT(JSON Web Tokens) and why it is more powerful than the traditional Session Management ? 
Tags: node, webdev, career
Published: 2020-10-11 07:06:58

While Working with any backend framework , I am sure you must have heard of this recurring term , **JWT(JSON Web Tokens)** , 
and I tried to gain more insight into this concept since past few days while working on my **Full Stack MERN Project** and thought why not share some insights , which can help other Developers in the Community as well. 

So , Let's get started and get to the meat of the things : 

**JWT or JSON Web Token** is basically a token which is used for authorisation of a **Client/or Host/or User** , and mind my words , it is used for **Authorisation** , not **Authentication** . There is a fine line difference between both of these two terms.

**Lets take a minute to understand both of these two terms as well ** 

Let's take example of Facebook, which we all use in our day to day lives : 

![Facebook Login Page](https://dev-to-uploads.s3.amazonaws.com/i/mhxmhmlwejwaqcrnvnql.png)

 Here, is the Facebook Login Page , You Enter your Credentials(User Name and Password Here), and Click on Log In. 

**When you are successfully logged in , and redirected to the home page of your News Feed, that is when you can say that you are successfully Authenticated by the Backend Server.** 


Now , since we are clear with Authentication , let's get to Authorisation . 

Now , let's suppose you want to update your Profile Picture on Facebook . Now, you are well aware that you are authenticated user, that's why Facebook Server has redirected to your Homepage. But, in order to update your Profile Picture on Facebook , you must be an Authorised User . 

**By Authorised in this context , I mean that you must have the access right and privileges, to make sure that Facebook's Server accepts your request, to update your Profile Picture on Facebook** 

Now , the question which arises here is that , How will Facebook get to know , that I am an **Authorised** User , and can successfully update my profile picture on Facebook.

It gets to know it through the help of JWT(JSON Web Token Only). Let's see how : 



![Session Management and JSON Web Tokens](https://dev-to-uploads.s3.amazonaws.com/i/9fh0l5y8341r3fo1u9rp.png)

In this above diagram, you can see two pictures. The First picture describes how things in **Traditional Session Management** Work , and the second picture describes how the process of Authorisation and Authentication works in Case of **JSON Web Token**.

Let's have a look at the Second Process as of now:

**Step 1** : In the Initial Step Number 1 , the client tries to login using their credentials. 

**Step 2** : After getting logged in , in Step Number 1 , and getting authenticated successfully, the backend generates a JWT Token and embeds it along with a secret key(**which is generated at the backend server side only**) and then that token is sent back to the Client/Browser.

Let's also analyse the structure of JWT also for a minute :

![Structure of JSON Web Token](https://dev-to-uploads.s3.amazonaws.com/i/36f6gzij0xp90w3bdkms.png)

If you take a look on the left side, the token is encoded and if you observe carefully , **there are 3 parts to this token**. These three parts are as follows : 

1). **Header**
2). **Payload**
3). **Signature**

**HEADER PART:**
The Header as you can see in the Screencast as well , contains information about the **Type Of Algorithm** with which the Token is encoded(**which is generally HS256**) and the type of token it is . 

**PAYLOAD PART:**
The Payload part is the main part, where the details of the client who is making a request to the server , so that the server knows that client is actually an authorised user and he is having the access privileges to access what is technically known as a **Protected Route** 

Payload is a **JavaScript Object** 

**SIGNATURE PART**

Signature Part is I believe where the real magic happens. It is where the Server in the Backend actually gets to know, that 
the User is who is trying to gain access to the **Protected Route** , should be given the access or not.

**Now,How does the Server Identify that ?**

When the Client to access a protected route , we know that along with the request , token is also sent and it contains details about the User , which are encoded in the Token Itself.

Now , in order to identify whether the User is authorised or not, the server checks that the token which is received along with request should not be **tampered/modified** by the client. In case , it is found to be tampered/modified , the request is immediately rejected.

**So, this is how the process of Authorisation with Tokens Work.**

Now, Coming to the Second Part of the Question i.e. **Why this Approach of Authorisation with Tokens is more powerful than traditional Session Management** 

Let's say , you have your Application and 2 server(**First is the Primary Server and Second is Secondary Server**). In Case the traffic load on one server reaches its threshold , all the requests are redirected to the Second Server. Now , Had we used the traditional session management , the Users who had been redirected to the second server , would not have been able to access the Protected Routes.
 
Reason being , in case of traditional session management, the data related to the User would have been stored as **Session ID in the Cookies of the Browser** , and since second server is not the primary server , all the requests of authorising themselves would have been rejected. 
 

**So, this was all about Process of Authorisation with Tokens and with the Help of Traditional Session Management**

I hope , I was able to provide some value with the help of this article. If you liked it , please share it so that other developers in the Community can benefit from it. **Thank You**