What Is JWT and Why Should You Use JWT

hello everyone my name is Kyle and this is web dev 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 JWT 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 JWT is then I'm going to talk about why you should use JWT and finally I'm gonna show you exactly how JWT 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 JWT works we need to understand what JWT is used for and JWT is just for authorization not authentication they're slightly different with authentication what you're doing is you're taking in a username and a password and authenticating to make sure that username and password is correct it's like logging a 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 ID that you send down in the cookies of the browser and then every time the client makes your request they send that session ID up to the server and the server checks its memory says ok what user has that session ID it finds that user and then it does the authorization to make sure the user has access but JWT instead of actually using these cookies

it uses a JSON web token which is what JWT stands for to do the authorization let's actually look at a quick graph to explain the differences first we're gonna take a look at a more traditional user login 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 login 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 user is correct and if that user is correct with the email password what they're going to do is they're actually going to store that user inside the session which is stored in the memory of the server and they're going to get a unique ID that corresponds with that heart in memory and they're gonna send that ID back to the browser using a cookie so that the browser always has that session ID that it sends up to the server every single time it makes requests 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 ID 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 ID that gets sent to me if so then it's going to say this is the user that

corresponds with that ID and it has access to that user to store 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 ok everything's good here's the information you were looking for the other form of authentication we have here is JWT so I'm going to get these two we can see both of them on the screen and it works very similarly at the beginning we make a post

request with our 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 JSON web token this JWT and it actually encodes and C realises that and signs it with its own secret key so the server knows that if you tamper with it then it's invalid it can actually check that based on the fact that it's signed it with a secret key then it takes that JSON web 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 JWT has all the information about the user built into it so it sends that JWT 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 happens the client is then going to send a request to the server and they're gonna make sure to include that JSON web

token so that it knows what user is authenticating with and the server what it does is it's signed to that JSON web token with its own secret key so what it does is it verifies that this JSON web token has not been changed since the time that it signed it because if for example the client changed it changed the user information in that JSON web token the server will now know and they can say that it's invalid but if for example nothing actually got tampered with the JSON web token is correct now what happens is

it just DC realises that JSON web 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 is 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 lookup to find the user based on the session ID

but with the JWT the JSON web 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 JSON web token across 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 depth on why this is really important and how this makes JWT so powerful later in this video but next

I want to show you exactly how JWT actually signs its tokens and how it can store the user information Here I am on a site called JWT 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 panes on the Left we have the encoded version of our JSON web token this is what you send to and from the client and this is how you authorize the user for different resources on the right we have the decoded version of

that JSON web 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 it 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 and as you can see over here the header is always before

the very first period inside of this and it's just base 64 encoded so here we have our header and this is just determining our algorithm and our JWT token type and really this is only useful for our signature portion at the very end where we're verifying it so we're going to kind of skip over this and go on to the second so which is our data and this comes in between the two other periods it's really nice JWT 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 T's for example this SUV which stands for subject this is just going to be most likely the ID 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 ID 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 users name but like I said you can put anything in this data component these are just some common fields that you've made all the time see another one that's really common is IAT 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 we'll also have something called exp or e8e

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 expire 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 can just use that forever and ever and ever always saying that they're 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 and 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 it actually takes the first two portions of the token so takes your header and it base64 encode it so you have this read section and then it adds a period and you have the purple section which is the base64 encoded payload so base64 encode 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 what it does is it uses the algorithm which is defined in the header here HS 256 you can change this algorithm if you want but this is just a good one to use it uses that algorithm and actually a secret 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 we'll use it and then what happens is it uses this algorithm up here HS 256 and it encodes your data portion so essentially all of your header information and your data information it takes all of that and it 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 going to combine it together down here as you can see they're gonna base64 encode the header they're gonna base64 encode the 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 JWT 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 unaccessible 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 anytime your 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 only when those two information pieces match do you know that they're exactly the same now that we talked a lot about how JWT works what it is we should finally talk about why you would want to use JWT and let's take a look at a very simple example of one of them common use cases of JWT here we have two different servers we have a bank that

owns a server that runs all of their banking applications their 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 web application but they want their users that log in to the bank to also be able to be automatically logged into the retirement account so when they switch from the bank to the retirement server they don't want the user to have to re log back in

especially if they make this transition very seamless to the user so it looks like they're on the same application this is really common in a lot of larger scale industries and applications and companies so what happens is the client makes a request here to the bank they say ok I want some bank information bank information blah blah blah they do all their banking stuff and then finally they get to the point where they actually want to access the retirement information and if you have a normal session based server what happens as your session is stored

here inside of the bank and not inside of the retirement server so what happens is your user needs to log back in because they need to be able to have their session stored on the retirement server because the session ID from the client is not found in the retirement server but when you're using JWT if you share the same secret key between both your bank and your retirement server then all you need to do is send the same JWT from the client to both of them and you'll be authenticated both times without having to re

log back in I know this is a little bit confusing to wrap your head around at first but essentially we're storing the user information on the client while in the old cookie session version we store it on the server and since we have two separate servers we need to have the information stored on both of them but that's not very easy to do or very possible so what usually happens is you have to store it on one place and then the user has to real aughh in when they go to the other place but with

JWT since the user information is stored in that token on the client it doesn't matter if they access the bank server the retirement server or any other server that this bank owns they're still going to be logged in because they have the same exact token and all the server's can recognize that token as long as they have that same secret key on the server another time that this is really used same kind of example with multiple servers is let's say for example we had two bank servers the bank was very large and they needed two

different servers to build a handle all of the users that were coming to the server and they have some form of load balancer out in front that distributed traffic to the different servers let's say that your client was accessing server a for a while and then this server it got really busy so it moved that client over to server B over here their session is no longer stored on server B it's only on server a so the user has to real aughh back in when this happens and with JWT you don't have to worry about

that because like I mentioned earlier the user is stored on the client that's really the important thing about JWT is the user is stored on the client so no matter how many different servers you have no matter how many different applications load balancers or anything that you have it doesn't matter if the user can always authenticate with any of those servers as long as you have the same secret key between them another instance where this is really useful is just you have a lot of really small services such as micro services where you may have

an API you may have an actual web server maybe even something else you can use that same JWT token from the client to authenticate with any of those different micro services all across your different architecture and now you know literally everything you need to know about JWT if you want me to make a video explaining JWT in nodejs let me know down in the comments below because I would love to make a tutorial on that for you also make sure to check out my other videos linked over here and subscribe to the channel for more

videos of me simplifying the web for you thank you very much for watching and have a good day