My name's Kyle and this is Webb.

Have simplified.

Now, if you're anything like me, you've probably heard of JWT.

You've maybe even seen a few videos on it, But you still have absolutely no idea how j w t really works or even why you would actually want to use it.

So today, in this video, I'm going to answer all of those questions for you.

First, I'm gonna tell you what J w t is.

Then I'm going to talk about why you should use Jada Beauty.

And finally, I'm gonna show you exactly how J W t works and how you can use it yourself.

So let's get started now First, before we can get into the nitty gritty details of exactly how J D B T works, we need to understand what J D B T is used for.

And J.

W.

T.

Is just for authorization, not authentication.

They're slightly different with authentication where you're doing.

If you're taking in a user name and password and authenticating to make sure that user name and password is correct, it's like a walking the user in.

But authorization is actually making sure that the user that sends request to your server is the same user that actually logged in during the authentication process.

It's authorizing that this user has access to this particular system, and the way that this is normally done is by using session.

So, for example, you have a session I D that you send down in the cookies of the browser.

And then every time the client makes a request, they send that session.

I d up to the server and the server checks.

Its memory says Okay, what user has the session, I d.

It finds that user, and then it does the authorization to make sure the user has access.

But J.

W.

T.

Instead of actually using these cookies, it uses a Jason Webb token, which is what J W T stands for to do the authorization.

What's actually look a quick graft to explain the differences.

First, we're gonna take a look at a more traditional user log in system that uses sessions and cookies to store the user.

So the first thing that happens is the user actually logs in from the client by posting to some kind of log in service with their email password for example, and as soon as that gets to the server, what's going to happen is the third server is going to do the authentication to make sure that that users correct.

And if that user is correct with the email password, what they're gonna do is they're actually gonna store that user inside the session, which is stored in the memory of the server, and they're gonna get a unique I.

D.

That corresponds with that part in memory.

And they're going to send that I d back to the browser using a cookie so that the browser always has that session I d.

That it sends up to the server every single time it makes request.

So, for example, down here, when the client needs to make another request, for example, they want to go to a new page in the application.

That session I D gets sent along with the cookie that it corresponds with.

So since it's a cookie, it gets sent along to the server and at the server.

What happens is it's going to do.

The calculation is going to go into the session memory, and it's going to check.

Do I have something in memory that corresponds to this particular I D.

That gets sent to me.

If so, then it's going to say this is the user that corresponds with that I d.

And that has access to that user cause it's stored that user in the session memory.

So now the application knows this is the user I'm working with.

Are they authorized to access this information?

If they are authorized, then it sends the response back to the browser saying, Okay, everything's good.

Here's the information you were looking for.

The other form of authentication we have here is J W T.

So I'm gonna get these to weaken, see both of them on the screen, and it works very similarly.

At the beginning, we make a post request for their email password, and we send that along to the server, just like before.

But instead of storing information on the server inside session memory, what happens is the server creates a Jason Webb token.

This J W T.

And it actually in codes and serialize is that and signs it with its own secret key.

So the server knows that if you tamper with it than it's invalid, it actually check that based on the fact that it's signed it with a secret key.

Then it takes that Jason Webb token, and it sends it back to the browser and notice.

The main difference here is nothing is stored on the server.

The server doesn't store the user.

Nothing actually happens on the server.

This J W.

T.

Has all the information about the user built into it.

So it sends that J W t back down to the browser, and the browser can choose to store that.

However it wants, For example, you could do cookie storage, and it would work very similarly to over here.

But anyway, that it happens, the client is then going to send a request to the server.

And they're gonna make sure to include that Jason Webb token so that it knows what users authenticating with and the server.

What it does.

Is it signed to that Jason Webb token with its own secret key.

So what it does is it verifies that this Jason Webb token has not been changed since the time that it signed it, because if, for example, the client changed it and changed the user information in that Jason Webb Token, The server will now know, and they can say that it's invalid.

But if, for example, nothing actually got tampered with, the Jason Webb token is correct.

Now what happens?

It just d serialize.

Is that Jason Webb Token?

And it says, Okay, this is the user information it's stored in that token already, so it knows exactly what to do with that user.

And if that user is authorized to use that resource, it'll send that response back down to the client.

Now, really, the main difference that you're going to his notice between these two is that in the session version, the information about the user is stored on the server.

So the server actually has to do a look up to find the user based on the session i D.

But with the J.

W T.

The Jason Webb Token.

What happens is the user information is stored in the actual token, which means it's stored on the client, and the server doesn't have to remember anything.

Which is great, because it means you can use the same Jason Webb token across the multiple servers that you run without having to run into problems where one server has a certain session and the other server doesn't.

I'm gonna go into a lot more death on why this is really important and how this mixture a DVT so powerful later in this video.

But next, I want to show you exactly how JWT actually signs it's tokens and how it can store the user information.

Here I am on a site called J w t dot io.

And I'm gonna link this in the description so you can mess around with it yourself if you want.

But essentially, what we have is two different pains.

On the left, we have the encoded version of our Jason Webb token.

This is what you send to and from the client.

And this is how you authorized the user for different resource is on the right.

We have the decoded version of that Jason Webb token, which has three distinct parts.

It has a header which determines the algorithm that you're actually using to encode and decode this.

It has the payload, which is just going to be all the information you store in the token.

And lastly and most importantly, we have this signature which allows us to verify that the token hasn't been changed by the client before it gets sent back to us.

So the very first thing we want to look at is the header.

As you can see over here, the header is always before the very first period inside of this and it's just based 64 encoded.

So here we have our header and this is just determining our algorithm and R J W t token type.

And really, this is only useful for our signature portion.

At the very end, we're very fine it So we're gonna gonna skip over this and go into the second section, which is our data, and this comes in between the two other periods.

It's really nice.

J.

W t actually separates things by periods, so it's very visually easy to see what the different sections are.

So here we have our data section, as I mentioned, and this is where you're going to put all of your different data for your application.

And there's some very common fields that you're gonna see across all different JW teas.

For example, this s U B, which stands for subject.

This is just going to be most likely the I.

D of the user.

You're authenticating lots of times.

You would store this in the session inside of your database or inside of your server.

But here you're just storing this idea directly in the token you're sending back to the user.

Next we have other fields.

You can put anything you want here, for example, we just have a name field here for the user's name.

But like I said, you could put anything in this data component.

These were just some common fields that you may all the time see.

Another one that's really common is I A T, which stands for issued at.

And really, what this is saying is when the token was created.

This is really useful.

If you want to actually expire tokens and you will notice a lot of tokens will also have something called E X, P E, or E 80 which is going to stand for expired at.

And this is just the date that the token no longer becomes a valid, and it's important a lot of times to have an expired date on your tokens, because otherwise someone else could take your token and use that to authorize themselves as you.

And if it doesn't expire, they could just use that forever and ever and ever, Always saying that there you even though they're actually or not.

So you need some way to expire your tokens.

So that sort of activity, it does not happen to your users.

Lastly, most importantly, we have this verify signature at the bottom on.

What this is going to do is it's going to allow you to actually verify that the user did not mess with the token before it got sent back to you.

And the way that it does that is that actually takes the 1st 2 portions of the tokens.

So takes your header and it based 64.

Encodes it.

So you have this red section, then adds a period and you have the purple section, which is the base 64 encoded payload.

So bay 60 foreign codes both of those sections, and combines them with period.

Essentially, all it does is it takes your header and it takes your payload and it combines them together.

So you have all of the data as it was when you sent it down to the user and then when it does is it uses the algorithm, which is defined in the header here.

HS 2 56 You can change this algorithm if you want, but this is just a good one to use uses that algorithm and actually a secret key, which you can define yourself.

For example, we could just find a key called secret.

That's a terrible secret key, but just for this example will use it.

And then what happens is that uses this algorithm appear hs 2 56 and Indian codes your data portion.

So essentially all of your header information and you're out data information.

It takes all of that and then encodes it using your specific secret key.

And that's what this blue section is.

It's the encoded version of your data that you have sent to the client.

So now if the client changes the data, for example, they remove this six from their data Now you can see immediately the signature is not going to match because when the client or when the server gets the information from the client, what they're gonna do is they're going to decode this top section.

They're gonna combine it together down here.

As you can see, they're gonna base 64 code the header.

They're gonna base 64 encoded payload, and then they're going to hash it with the particular algorithm and they're gonna check.

Does it match the last portion of the key?

If it does match the last portion of the key, then you know that the user did not mess with anything.

But if when they hash it, as you can see up here, they get a different result.

For example, when you hash this information, you are not going to get this blue section.

So they know immediately that this key has been tampered with and that the data in the jade of beauty is no longer valid.

And that's why you can actually store user information on the client.

And you can actually trust that they haven't changed it because they would have to have your secret key.

If they ever did get access to your secret key, then they would be able to fake changes.

But that's actually not going to happen as long as you safely store your secret key on your server and un accessible to other people.

outside of that server and hopefully that made sense.

This really essentially works a lot like password hashing in the fact that the header appear and the payload are actually combined together and then hashed in a way that they cannot be unhatched and the way that it checks here.

This blue section is just the hash of those two.

So any time you're data is changed, the two hashes will no longer match.

Which means that you know that the data that the client is sending you is not the same as what you originally sent them yourselves on Lee, when those two information pieces match, do you know that they're exactly the same?

Now that we talked a lot about how jaded beauty works, what it is, we should finally talk about why you would want to use J.

D beauty.

Let's take a look at a very simple example of one of the most common use cases of jade, a beauty.

Here we have two different servers.

We have a bank that owns a server that runs all of their banking applications.

They're banking website, all of the bank information you could think of.

But they also own a separate server, and this takes care of all of their retirement plans.

They allow people to invest and do retirement plans on a completely separate REB application.