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 :
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 :
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 :
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
Top comments (7)
Biggest question is how to save those JWT in frontend... Do Facebook also uses localstorage or we hve something good place to store tokens. If yes are they cookies?
HIi G.V.S Akhil ,
Coming to your question , if we will store the token in the LocalStorage then it will pose a problem , reason being , after storing it inside LocalStorage , any malicious script can try to access it and tamper it. As far , I have researched it's stored in cookies only but it is a special type of cookie which is known as httpOnlyCookie. It is a special kind of cookie that's only sent via HTTP Requests to the Server and any external maclicious script of the browser cannot access it.
I hope that answers your question.
Can u post the code thats used to store in a httpOnlyCookie??? I tried a lot but couldn’t find it
I found one here thanks medium.com/@ryanchenkie_40935/reac...
Hii @G.V.S Akhil ,
I have worked with JWT in My Recent Project , and if you talk about storing the token in a httpOnlyCookie in the context of Code , then sorry there is no line of code which exactly is clearly signifying that the token is stored in a httpOnlyCookie . I believe that , the jwt package is doing all of the heavy lifting for us in the backend , and even though we are not able to see it in our code , but it is surely being stored in a httpOnlyCookie.
I hope that answers your question
I think also a good point to mention is that JWT can contain a payload. A very good example of how that helps is for granular approach access control. This information can then be used in frontend to handle various flows.
I can't believe people still use JWT, it's bad.