Lecture thumbnail 0:00 / 0:00 If you want to enable security for your web API controllers,
JWT is the most preferred and followed way in the real-world projects.
So let us try to learn how do you enable JWT.
First, in this lecture, we will understand its basics.
What is JWT?
As you can see, JWT is JSON Web Token.
That means that JWT is a token system
that is exchanged from the server to client.
It is a form of representation of the user data,
which is also called as user clients.
At first, the user will sign in by using his email and password,
and the server will generate a token automatically for the same.
So that token includes the user details.
This particular token will be sent back to the client,
and in the browser, we will store the token
within the session storage or local storage.
Then for all the subsequent requests,
the browser has a responsibility of claiming that the user is already logged in.
In order to do so, the browser automatically adds the JWT token
as a part of the request header,
that is authorization request header.
For example, the browser makes a request
and in the request header called authorization, the token is included here.
Then that particular token will be verified by the server,
identifying that token is valid,
and checking the user details that are part of the token.
If that sounds valid,
then the appropriate code will be executed on the server,
such as executing an action method of the controller.
Then appropriate response will be sent as usual.
So first, the token is generated by the server, given to the client.
For all the subsequent requests,
the token is included in the request
and will be received and verified by the server.
So this is the overall process what exactly happens with JWT authentication.
This is more secure than just storing user ID or user details in the browser memory.
Because if just user details are stored as a token in the client,
if someone knows the user details
and he can make a request to the server claiming that the user is logged in.
For example, Mr. X is the hacker and he got the user email address
and he can make a request to the server
and the server will process the request.
It is not safe.
So that is the reason there must be a trusted way
that other than the server,
no one else should be able to generate that particular token
that is accepted by the particular server.
So there is a necessity of generating the token along with the security key
that is only known to the particular server,
not by some other server or somebody else.
So that is how the token is generated in this case.
But what are the contents of the particular token?
Every JWT token contains three parts, something like this.
This is the overall look and feel of a token.
It includes with three parts,
header part,
payload and signature.
All these three are the base64 strings.
If you wonder what is a base64 string,
it is a form of data that is used to encode the binary data in a printable text format.
So behind every base64 string here, there is a normal data.
Either it is the plain text or a JSON object
that is converted into the base64 string by using an algorithm.
The base64 string algorithm is not a secret one that is known to everyone.
Even any developer can easily convert the data into base64 string.
What I mean to say is that it is not a secured algorithm.
Here, the header contains the details of the token,
indicating what secured algorithm is used in order to generate the token.
And the payload contains actual user details that you want to store.
For example, if user1 is logged in,
so we will store its details such as user ID, email address,
or user type, or user role, etc.
You can include any non-sense-to user details as a part of the payload,
such as user ID, email address, etc.
But you should not include any sensitive data about the users in the payload,
such as, for example, the passwords,
any financial information, etc. should not be as a part of the payload.
Because if someone knows the token,
he is able to reverse the base64 string,
can easily get back the actual information behind the particular payload base64 string.
So if you apply a reverse algorithm,
you can convert this data and get back the actual data behind it.
And the signature is the encrypted version of the same header and payload.
It is generated by using a cryptographic algorithm that is HMAC.
Let us understand the scenario.
For example, the header is this one,
a JSON object which contains the type,
that is JWT.
It is a constant value always,
because we are trying to generate a JWT token always.
But the second value ALG indicates algorithm.
It indicates the algorithm that is being used to generate the signature.
And the payload contains the user details,
such as user ID, email address, and the user role, etc.
And the secret is a string value that is only known to the particular server,
not by somebody else,
not by any other developers,
except for the people who are working in the same organization.
So these are the inputs that are required in order to generate a JWT token.
And the process here is that,
first we will take the header,
and we will convert the same into base64 string.
So this is the mathematical representation of the process.
Here you can assume that the base64 encode is a mathematical function,
which takes any data as input,
and converts the same into base64 string as return value.
So in this part, we will convert this header into base64 string.
And then we will concatenate dot as a constant.
This dot is used for separation between the header and payload.
So then after that,
we will take the same payload which contains the user details,
and we will supply the same to the base64 encode function,
means we will convert the payload into base64 string.
So as a result, we got the data,
which contains the header as base64 string,
something like this, for example,
and then a dot as a separator,
and then the payload as a base64 string,
for example, this one.
So this is the base64 string representation of the above mentioned header as an example,
and this is the base64 string for the above mentioned payload.
So we have these two values together,
that is called data.
Then we will hash the same here by using a secured hash algorithm.
For example, we use HS256 algorithm.
For this cryptographic hashing algorithm,
not only the data, but also you require a secret value,
that is the third input here.
So as a result of this hashing algorithm,
it hashes this particular data along with this secret value,
and it generates a hashed data.
And then finally,
the signature is the base64 string encoded version of the same hash.
For example, this hashed data is equal to 1234.
Then we will convert that 1234 into base64 string,
and that is called a signature here.
For example, this one over here.
So finally, we will concatenate everything together.
The data already contains the header, dot, and payload,
and then dot again for separator,
and then the signature.
From where we got signature?
The signature is the base64 string of the hashed data,
and the hashed data is generated based on the secret.
And this hash value is generated based on the header and payload.
So logically, this signature actually generated based on
the header and payload.
So this is the internal algorithm process in order to generate that token.
Suppose as a developer, you are asking that,
do I need to write actual code for converting the data into base64 string
and the generation of the hash?
No.
There is an existing NuGet package that automatically does the same algorithm
that is mentioned here.
So you need not write actual code for converting the data into base64 string.
Or even for hashing.
Only the thing is, you have to install that NuGet package
and pass essential inputs, such as passing the header, payload,
and secret values, and essential configuration if anything is required.
So this particular algorithm process will be automatically taken care of
by that NuGet package.
Overall, as a summary, the JWT token is the secured way
to represent the user details.
But how do you ensure that this token is generated by the particular server?
It is because the hash is generated based on the secret value
by using a secured hashing algorithm.
So if any malicious user is trying to mimic the process,
he do not know the actual value of the secret,
which is known to the same server,
which is generally stored in the environment variables of the particular server.
So on the production scenarios,
that secret value is not even known to the developers.
At development time, the developers may use some dummy secret values,
but the actual secret value on the production server would be different.
The production-level secret value will be stored only on the web server
as environment variable.
So in that way, the server can easily identify
whether this token is generated by the same server or by somebody else.
In case if the server has received a token,
if that token is not generated by the same server,
it cannot be reproduced by the same server
because the secrets doesn’t match.
That is the reason why JWT is secured.
Here in this context, the client,
that means the browser doesn’t verify anything related to the security.
It simply receives the token,
stores it on the browser memory,
and sends the same token as a part of the request header to the server.
The client doesn’t verify anything actually.
The process of creating the token
and verifying the same token on the subsequent requests,
both of these tasks done by the server itself.
And if you ask me,
how does the server verify whether the token is valid or not,
in short, it just repeats the same process
based on the header on payload
and it gets the new token.
So if the newly generated token
and the token which was supplied by the client
as a part of the request header matches,
then it is valid.
In case if they do not match,
it is treated as invalid token.
Let me explain.
For example, we have got exactly the same token
from the request header.
That is authorization, bearer,
and then this particular token is present.
So we got this token as a part of the request header.
Then the server has to verify whether this token is valid or not.
Then it will try to perform the same algorithm one more time
to generate a new token now.
You should remember that
the base64 encode algorithm and hashing algorithm
both are different.
The base64 encoding algorithm is reversible.
That means if you already have a base64 string with you,
you can convert the same in reverse,
means you can decode the same
to get the actual data behind it.
But if you have a hash value with you,
you cannot decode the same.
There is no reverse hashing process.
Once the hash is generated and that’s it,
even though you have the secret value with you,
you cannot unhash the same.
You cannot get actual data behind the hash value.
So keep these points in mind.
Now, in this particular token,
which was received from the request,
we have the header and payload values, right?
These are base64 strings, right?
So you can decode this base64 string
and you can get back the same actual header value
as well as payload value with you.
Then we will continue the same algorithm.
That means once again,
we will convert the header into base64 string
and then payload also into base64.
And then we will hash the same
based on the same secret value
that is already known by the server.
Then that hash will be converted into base64 string.
So you will get the signature.
So you got the new token
by concatenating the same with dot.
The data is header dot payload
and this signature is the base64 string version of hash.
So you got the new token.
So this particular token
and the token which was supplied by the client must match.
If they do not match,
it indicates that the token was generated from another secret
which is not actual secret of the server
or the person who generates the token
is using a different algorithm
other than this one that is mentioned here.
So in this way,
the server verifies whether the token is valid or not.
So overall,
you can believe that the JWT token
is one of the most secured ways
to authenticate web APIs in these days,
which is widely used in most of the projects.
But how do you write the code
for creating the token
and verify the token in ASP.NET Core?
We will try to do that in further lectures in the same section.
Play Play Play Play Play Stop Play Play Play Play Play Start Start Start