JSON Web Token basics - React.js Tutorial

- [Instructor] Okay, so at this point we've got the basic framework for our authentication app set up. We've set up our project and created several useful components. So now that we have all of those things, we're ready to start adding real user authentication techniques to our app. Now we talked earlier about the three main classes of user authentication, that is knowledge-based, ownership based and biological based authentication. And in this course, we're going to be focusing mainly on knowledge based authentication. That is the techniques we're going to be using will be focused on verifying users based on passwords. Now, in order to understand how exactly this password based authentication is going to work in our application, it's very important for us to talk about something called JSON Web Tokens. JSON Web Tokens which are commonly abbreviated as JWTs and sometimes called jots, although in this course, I'll just be calling them JWTs, they formed the figurative beating heart of most modern website authentication. So let's take a look at exactly what JWTs are and how they work. So, first of all, what are JSON Web Tokens? Well, JWTs basically unique strings that we give different users of our site after they've logged in. And the idea is that whenever a user wants to interact with our site in some way as that user, for example, if they want to update their information in our day database, instead of having to send their password to our server every time, what they can do is simply send us this string instead. Send us this JSON token. Now JWTs aren't just any string, they're actually an coded JSON object that contains information about the user. So it might contain things such as the user's ID, the email address, their basic information, et cetera. Basically anything that will make it easier for our app to decide what to show them and what they're allowed to do. So the next question is what exactly do JWTs look like? Well, here we have an example of what a JWT might look like. They'll usually be quite a bit longer than this one that we see here. This one is just shortened for simplicity sake. So JWTs have three separate parts separated by periods. They have a header, a payload and a signature, and each of these sections is a JSON object that's encoded, usually in base 64. That's something we'll have to keep in mind when working with them on our front end backend as you'll see. So here's what each of these parts has meant to do. The header basically it tells us, the type and signing algorithm of the token. So this could be something like HS256, that's the most common one to use. So next up the payload is the actual data that the JWT contains. So for example this could be the user's profile information. Now the pieces of the data in the payload are referred to as claims and we're going to see how all of this works very shortly. And finally we have the signature. Now this is where things get interesting and where the actual usefulness of JWTs becomes apparent. The signature of a JWT is used to prove the authenticity of the data that the JWT contains in its other parts. Now it's created by combining the header and payload and signing those using the specified algorithm and a secret key which we'll define ourselves on the server. Now, what this means is that anyone who has the token can see the information it contains, unless it's encrypted of course, but they cannot change the data in the token unless they have the private key, which definitely should not be the case since our server should be the only one that has access to this private key. And you'll see how all of this works again very shortly. So now that we know the basics of what exactly a JWT is, let's briefly walk through the steps of how JWTs are used in full-stack applications. And this flow is what we'll be implementing throughout the rest of this section. So step one is that the user logs in successfully to our application, right? This will mean that they send along their username and password to our server, and our server will check that, if it's correct, the user is considered fully logged in. So if a user is able to log in, if they provide the correct password, the next thing our server is going to do is use a secret key to generate a token containing the user's information. Now again, only the server knows the secret key, so only the server knows how to sign the token correctly. Step three now is that the server will send this token back to the user, followed by step four which is that the user's browser will hold onto this token usually by storing it in cookies, session storage or local storage. And obviously each of these methods of storing the token has its own benefits and drawbacks security wise. After that, step five is that whenever the user wants to make a privileged request now, for example, to an end point that they can load their private information from or modify their information in our database, they're going to send this JWT along with their request. And step six is that the server is going to use that secret key again to verify that the token that the client sent is legitimate and hasn't been tampered with. So in other words, it makes sure that the client hasn't tried to make themselves look like another user by changing the ID property in the token. Okay, so that's the basic process of using JWTs. Before we move on, there are a few more things that I want to mention about JWTs. The first thing I want to point out is that when the front end sends a JWT to the server, it will usually send the token in a request header that looks like this, right? It'll be an authorization header that will say bearer space and then it will have the actual token string in there. This is just something you'll need to know when we're parsing the token on the backend. The next thing you should know is that tokens are credentials and they need to be treated with care. So you're never going to want to give anyone else access to your JWT tokens. You're never going to want to display them in a public place, and as a developer, you're obviously going to want to make sure that the user's JWTs are as secure as possible. The next thing I want to point out here is the difference between signing and encoding tokens and encrypting tokens. Unfortunately, these two concepts do seem fairly similar to each other at first glance, but there's actually a very big difference between them. You see signing tokens prove that the information is intact and hasn't been tampered with, right? All signing does, is proves that the server is the one that generated the token, since the server is the only one who has the secret key. Now this is very different from encrypting tokens, since encrypting actually hides the information from third parties that the tokens contain. And JWTs are not encrypted by default, so do not put secret information in JWTs unless they're encrypted or unless you're using HTTPS, which is something we'll talk about later in the course as well. Now, the final thing that I want to talk about with JWTs here is some of the benefits and drawbacks of JWTs. Some of the benefits of JWTs include that they're stateless. So in other words, all of the information that JWTs contain, is contained inside the token itself. And what this means is that it doesn't require our backend to actively keep track of who's logged in, right? So in our database, we don't have to set properties on users saying logged in equals true, logged in equals false, et cetera. The other benefit of JWTs is that they use JSON which means that it's very compact compared to some of the other options like XML and it's more secure as well since signing JSON is easier and generally less vulnerable than signing XML. And now let's talk about some of the drawbacks of JWTs. The first drawback is that, because of the way tokens work, they'll remain valid until they expire or until the private key on our server is changed. So if a user's account gets hacked, for example, there's not really a good way to kick the hacker out even after the user changes their password since the hacker will still have that JSON Web Token. And this also means that it's hard to block specific users at least not without making our JWT flow stateful by having a database of blacklisted IDs, for example. And as we'll see later on, this also means that logging out is achieved by simply deleting the token from the browser. Since again, there's no state to say that a user is logged in or logged out in our database. We'll see how all that works later. Now, the second drawback of JWTs is that the standard itself, the JSON Web Token standard doesn't define a process for refreshing tokens. So when the token expires, the user will have to reauthenticate. So they'll have to log in every two days or something like that, however long we set the expiry date.