JSON Web Token Explained
There are quite a few ways to perform authentication for your web application now, but why JWT when you already have cookies and others in the place. Let’s see the differences and benefits that JWT brings to the table.
If you are opening a website for the first time, if the website is a medium to large scale website, they would most probably use cookies to store your data in the browser. Why store cookies, cookies help in authentication your session easier so that you don’t have to sign in every single time when you open a website in your browser, cookies may also store your preferences for the website, so that you don’t need to customize some settings every time.
So how does the cookies architecture work, on loading a website for the first time they store cookies with randomly generated text which will also be stored in the database of the application? So when you come back to the website, instead of prompting you to sign in again, the browser sends the ID in the HTTP header and the backend code that you have validates the ID by fetching the ID-related information and verifying, once the database returns your credentials, then the backend-server would return the rest of the code, so that you can continue using your application hassle-free.
So, what’s the problem with cookies, If you take a look at the architecture, you’ll find out that for every new session you have to fetch the results from the database which would become expensive when you have a good lot of users, browsing through your application, also if your database is hosted in a VPC (Virtual Private Cloud) then only a handful of computers will have access to the database. So, if you try and remove this database retrieving, it would reduce the cost and the process of authentication as well, and this is where JSON Web Token comes in.
How does JSON Web Tokens Works?
If you are considering a cookie it contains only the site name, expiration date, and the Unique ID that it has to send to the backend server, but in the JWT it contains the user data but is encrypted using a signature that can only be decoded by the backend server, so for revalidation the token is sent to the backend, the backend script has a secret key, which checks the data and validates it and makes sure that the data has not been tampered with, and once the validation is done the backend sends the user data to the browser, by following this process, you don’t need to query the database for regular authentication anymore. The overview of how this works can be seen in the below image as well.
Also if you have hosted your database on a VPC (Virtual Private Cloud) then the process of retrieving and verifying the cookie would be tiresome and JWT removes the need to contact the database, because of its architecture.
JWT also proves to be very useful in a microservice architecture if you are hosting the services independently like cloud functions, by using JWT the cloud functions now have to authenticate a session independently and also have the chance of communicating with other functions securely.
JWT String
If you take a look at the JWT string you’ll understand that it’s a three-part string separated by dots i.e. xxxxx. xxxxx.xxxxx, now that we have analyzed the structure of the string it’s time to know what does each part does and how when combined they are secure. The most important part of the string is the middle part which stores all the data that has been sent by the backend it’s encrypted in base64 which means that anyone and decrypt it as shown in the image below. This may raise a doubt then how is JWT secure. Now let’s discuss the other two parts of the string, the first part is the encoding that is used to encrypt the data and the encoding string itself. The most common encoding used here is HS256, and the third part of the string is the signature in which is a combination of the data and the encoding. So if you have tampered or changed the data in the JWT token, when it’s sent to the backend, it will realize that the token sent has been tampered with as the signature varies from the one in the backend and hence rejects the request from the browser.
Conclusion
JWT reduces the requests that we have to make on databases, makes the authorization process more easy and fast, despite having all the good things, it has one major drawback which can affect if you are trying to implement a revoked access system for your application. JWT string is stateless it does not maintain its active state but has an expiry set to it, so till it reaches the expiry date it can stay active and cannot be revoked by any means. This drawback will most likely not affect small to medium projects, but if you plan to have options like Sign Out from all devices that you must consider sticking to the cookie approach so that you can log out of every device that the user has been logged in from, but if you are having a micro-services based architecture then JWT can be your go-to solution.
You can watch the full YouTube video here
Sharing is caring
Did you like what Pranav wrote? Thank them for their work by sharing it on social media.
No comments so far
Curious about this topic? Continue your journey with these coding courses:
Ewomazino Akpareva
HTML CSS and SASS Bootcamp