In this area, let's try to understand what the JWT and what at once features that it provides compared
to normal tokens that we have discussed in the previous reviews.
So firstly, JWT means Jason Webb token.
That's a full expansion of it.
It is a token implementation that leverages Jason format designed to use inside Web request.
And it is the most common and favorite token type that many systems and users applications that they
use these days due to its features and advantages like very lightweight.
And it uses Jason format, which can be understood by everyone.
And at the same time it allows us to send the data in an encrypted format.
JWT tokens can be used beyond authentication and authorization.
Like if I want to share certain information or if I want to store certain information inside my token
itself, rather than storing inside the service memory, which will degrade the performance of the server
over a period of time.
What I can do is I can store all such information that I want to communicate to.
The other system are for my future reference inside my token, excel in an encrypted format.
So basically JWT token has three parts which are separated by dots.
You can see below is the sample JWT token that code generator and the very first, a local related part
is it had their part and right now this is all base64 encoded value bozkurt.
After the first dot we have a payload, our body part of the token where we store all the user related
information or any other information that we want to store for ourselves.
And lastly, we have a signature part and this is an optional only if we are going for the encryption
and if we want to make sure that no one tampered you had that and body parts of your token, then only
you will use this last part, which is a signature.
But otherwise, header and bodies are mandatory sections, whereas signature is an optional one.
So if you go and look the header part, so usually we use header pad to store the metadata, our info
related to the token, like what type of algorithm I have use to generate the signature of my token
or what is a type of token, is it a JWT or any other token type, etc..
So initially when we generate a token, this is how the data looks.
Was that before sharing to the client that will be converted into base64 encoded so that people on the
other side they can easily decode using base64?
Both the header part we have it by the part where we can store is related to user the rules, which
can be later be used by authentication and authorization purposes.
And there is no limitation what we send inside the body and what is the size of it.
We can send any size of the data inside body part, but it's our responsibility to keep it as light
as possible so that we don't create latency issues in the network here you can see inside the body and
storing sub name and eighty eight means issue time issue out.
What is the time that I have issued that Goken post?
The body will be converted again into the encoded format.
So you can see here what is a need for me to store the data inside the body of the token.
There are two reasons.
One is you want to share the information on the other side of the parties so that they can also use
these rules and authorities that you are sending for their business logic and the other purposes.
If you go with the traditional ways of generating a Shushan, you have to maintain all such details
inside your database, like what is the Shishani when I have created what is the exploration aim of
it.
So all such details, you have to store it in some memory location are some database.
And every time for every request, you have to retrieve those details and compare what you have received
from the client to avoid such scenarios.
We can maintain such information like I have created this token at this point of time and this is the
expiration time of it.
So all such information I can maintain inside the token itself so that we don't have to maintain such
information inside association, subversion, our memory, our database.
So now we have an understanding of what is header, what is body.
Let's try to understand the most important part of the JWT token, which is a signature value.
I was think of a scenario where I am generating a token and I'm sending the token to other internal
application inside my company firewall.
So in this scenario, I'm pretty sure no hackers can access my token and they can't tamper that valuable
tool for such scenarios.
I can simply send the header and body of the token since I'm believing the other side of the application
and we can communicate any such information between my application and the other side application.
But if we have a scenario where the token will fly into the open world through the web, then we have
to make sure there are enough measures to detect that someone tampered that token because you are not
storing that token anywhere inside or backend application like in the server memory database.
Then how do you validate if someone sends whether this is the reality that you generate or not so far
that we use the digital signature.
So what we do is we generate a hash value outside header and body value that got generated in the token.
We send that hash value inside that token also.
And if someone tampers my head and body values from the other side of the party and send the value again
to me, what my backend application will do is it will try to isolate the hash value of the header and
body again and compares that already value present in the token with the newly generated hash value.
And if the both matches when it's a match, just not the content but the hash value of the both values
matches, then it believes, OK, this is my original token, that a generator and no one tampered the
token.
So that is the purpose of the digital signature inside our JWT token.
And the way that we can create this JWT token is you can see here we can choose the encryption algorithm
that we want to use as the base64 encoded had better value darte base64 encoded the value of the payload
along with the secret code that you maintain in the server side.
So this secret key will play a very prominent role in generating the hash value outside from your Heidrun
Bellard values.
So on a high level, this is how the token looks.
The very first part is header and next is already our payload and the last one is the signature.
So all these parts are separated by the dots present in between and JWT tokens are heavily used in the
history, email and environment, and they have a great advantage compared to small tokens which are
XML based standards.
And since Jason Tokens uses this Furman, they're very light in nature.
You may ask why do you want to send the base64 encoded value that had better body?
You can also encrypt and send that Heidrun payload to provide more security on top of hash value that
we maintain in the signature value.
Yeah, even that scenario also is very valid if you have a stronger requirement of encrypting even the
header and body so that no and authenticated application NCUA actual value is present inside header
and payload, you are free to use them.
But please remember, whenever you introduce encryption and decryption unnecessarily, it will use a
lot of your server computations values so that by default you can always send your header and body in
base64 encoded value, since that is very easy to decode and you can protect those values by generating
a signature and hold it in the signature part.
So in this way you can maintain the credibility of your token and make sure no one is putting your token
in the next.