Node Auth Tutorial (JWT) #10 - JSON Web Tokens (theory)

Key Takeaways

so imagine that we want to log into our application from the browser well first of all the user logs in via a web form from our website which sends a request to the server with their credentials an email and a password the server then checks those credentials the email and password against those stored in a database for that user now if they are correct the server then creates a json web token for the user and it sends it to the browser where it can be stored in a cookie the json web token contains encoded data about that user to identify them so for as long as they have this token in the cookie then they are considered logged in and authenticated so now the user has this json web token stored in a cookie in their browser now remember cookies are sent to the server by the browser for every request they make eg for new pages on the website so when the server gets that token from the cookie in the request it can verify it and decode it to identify the user now if it is verified to be a valid token the user can be seen as logged in by the server and the server can then decide to show the user protected data or pages which require the user to be authenticated if the token is missing or not valid the use is not authenticated and the server can send back some kind of error or direct them to the login page or something now this process is a little bit more complex under the hood but we're going to look at each stage in detail as we create the authentication process and like i mentioned in the last video there is a pitfall to watch out for when using jwt's inside cookies for authentication it does potentially open up your site to cross-site request forgery attacks now that basically means that a malicious site can take a user's authentication cookie and then make requests to our server posing as that user now if our server exposes state changing end points then this is a security risk because it means that the malicious site can then manipulate your user data and potentially access more of it now in our case we won't be exposing any state changing endpoints that require authentication so there is minimal risk for us but for larger more complex websites with state changing end points you will want to negate that security risk as best as possible so i'll leave a link below with more information about that which i highly suggest that you read for now let's talk a little bit more about how these json web tokens are created and verified okay then so i'm on the jwt website which is jwt dot io and this is a really nice place to see how tokens are made as well as for debugging tokens as well so if we scroll down here right here we can see a json web token which is basically an encoded long string of characters made up of three parts you see we've got three different colours right the red the purple and the blue and they correspond to these three different parts which are the decoded versions of those three strings so the first one the red part that is the token header which is a bit like metadata for the token now the second part is the payload and that is data that is encoded into the jwt now this could be a user id to identify the user so that when it's decoded on the server we know which user is going to be logged in now it's important that no sensitive data is put inside this payload in case a token is intercepted by somebody because it can be decoded by anyone that knows how now the last part is the thing that kind of ties everything together and we're going to talk about this a little bit more in a minute that is a signature and that is used to verify the token on the server now notice this if i change something over here for example in the payload then all of this changes on the left as well so changing the data embedded inside of this changes the resulting encoded token so this token this is the thing that is created on a server and then sent to the browser and potentially stored in a cookie so now what i'd like to do is explain how this kind of works under the hood and explain what this signature is for right here okay then so we know the three different parts that jwt is made up from the headers the payload and the signature but why do we need all of those three parts and how do they all work together to authenticate and verify users well first of all the headers are needed because they tell the server what type of signature is being used it contains metadata about the token the payload is needed because when it's decoded it's going to help us identify the user on the server and it will contain something like the user id now the signature is the thing that ties everything together and it makes the jwt secure and it makes sure that tokens are not tampered with on the client it's a bit like a stamp of authenticity from the server now the way they all work together is like this when our server is creating the jwt after a user successfully logs in or signs up then it creates the header part and the payload part first and encodes them both then to sign the token or to add the signature it takes both of those two parts and it hashes them together with something called a secret which is a secure secret string stored on the server now this secret must remain a secret because it's the key to unlocking the jwt and the only way to verify a token so you would never publish the secret to any kind of public repository where anyone could see it so when those three things are hashed together it creates the token signature now the token signature is then added to the end of the jwt after the other two parts and it can be sent to the browser so the actual hashed resulting token would look something like this so our jwt is then added into a cookie and sent and stored in a browser so for any subsequent request to the server the token is then received by the server inside that cookie the server can then verify this token on every request by looking at the header and the payload and hashing them with the secret which remember is stored on the server if the hashed value of those two things with the secret matches the signature which remember is also the hashed value of those two parts and the secret it knows then that it's valid and the jwt has not been tampered with on the client if the jwt had been tampered with on the client for example the data in the payload modified then those two parts either the header or the payload would have been changed right the encoded parts and when they're hashed together with the secret they would not match whatever the token signature is and therefore we would say hey no you're not logged in you're not authenticated anymore so this whole process of signing and verifying jwts might sound a little bit complicated but with the help of the json web token package that we're going to install soon it's actually really really easy to implement so anyway that's a bird's eye view of the authentication process that we'll be using with jwts and we'll start that process in the next video