**Creating an Authorized Request with Angular and Express**

To create an authorized request with Angular and Express, we need to first ensure that our application is sending out requests with the correct authentication headers. In this tutorial, we'll explore how to achieve this by utilizing Angular's HTTP client and implementing an interceptor to attach the necessary authentication tokens to each request.

As mentioned earlier, if we get a response from our server, we're going to print the message attached to that response. This will help us verify that our application is successfully authenticating with the server. However, if there's an error in the response, which would be a status of 401 or unauthorized, the message will indicate that we are not authorized to visit this route. We've seen this earlier in the browser, and it serves as a reminder that our authentication mechanism is working correctly.

To further verify the authenticity of our application, let's create an AuthInterceptor that intercepts every HTTP request sent by Angular and attaches or runs the intercept method. The interceptor will first grab the token from local storage and then check if there's an ID token associated with it. If there is a token, it will clone the current request and set the Authorization header equal to the ID token in the format "Bearer ". This ensures that our requests are properly authenticated with the server.

However, if there isn't a token in local storage, which would be the case if the user is not logged in, the interceptor will simply return `next.handle(request)` without attaching any authentication headers. This approach allows us to manage our users' permissions and implement custom logic within the interceptor to determine whether to attach the JWT or not.

To test this implementation, let's visit our protected route in the browser. Ideally, if we log in earlier, we should see that we're authorized, and our request will include the token in the Authorization header. To verify this further, let's open up the Network tab in our browser and click on the Protected route. We'll then examine the request headers to ensure that the Authorization header with the JWT is being attached correctly.

**The AuthInterceptor Implementation**

Here's the implementation of our AuthInterceptor:

```typescript

import { Injectable } from '@angular/core';

import { HttpInterceptor, HttpRequest, HttpHandler } from '@angular/common/http';

@Injectable()

export class AuthInterceptor implements HttpInterceptor {

intercept(request: HttpRequest, next: HttpHandler): Observable> {

const token = localStorage.getItem('token');

if (token) {

request = request.clone({

setHeaders: {

Authorization: `Bearer ${token}`,

},

});

}

return next.handle(request);

}

}

```

As we've discussed, this interceptor will first grab the token from local storage and then check if there's an ID token associated with it. If there is a token, it will clone the current request and set the Authorization header equal to the ID token in the format "Bearer ". This ensures that our requests are properly authenticated with the server.

If there isn't a token in local storage, the interceptor will simply return `next.handle(request)` without attaching any authentication headers. This approach allows us to manage our users' permissions and implement custom logic within the interceptor to determine whether to attach the JWT or not.

**Conclusion**

In this tutorial, we've explored how to create an authorized request with Angular and Express using interceptors. We've discussed how to ensure that our application is sending out requests with the correct authentication headers and implemented an AuthInterceptor to attach the necessary tokens to each request. By following these steps, you can implement user authentication in your Angular application and understand how JWTs work.

The most important thing to take away from this tutorial is understanding how everything works and being able to implement your own authentication strategy. With a solid grasp of user authentication concepts, you'll be able to tackle more complex applications and scenarios with confidence.

**Acknowledgments**

If you watched all the way through this tutorial, we'd like to extend our gratitude for your dedication and perseverance. It's not an easy feat to complete a tutorial spanning multiple hours, but we appreciate your effort in understanding these concepts.

To those who managed to go from the very beginning of this course to the end without skipping any sections, please reach out to us on Twitter (@zg_dev) and share your thoughts on the tutorial. We'd love to hear about your experience and what you thought of our efforts.

Finally, if you're interested in exploring more coding concepts and tutorials, be sure to check out our smaller YouTube channel. We'll continue to post new content and tutorials, so stay tuned for more exciting projects and information. Until next time, we bid you farewell!

"WEBVTTKind: captionsLanguage: enwelcome to my complete beginners course on user authentication in web apps in this course we're going to be talking about how do you actually write that register form or the login form for your users using node.js express and passport.js and then later in the course we'll actually go into how do we apply these strategies to an angular application and then even further how do we write our own custom jwt authentication option but before we get into that i want to just introduce myself i'm zach and i'm a full stack developer i've got a smaller youtube channel where i cover a lot of these topics and i've been writing code for about four and a half years pretty much every day at this point and i'm super excited to share this particular series because it was one of the biggest struggles that i had when i was first learning to code i struggled with it for two main reasons number one i was scared of it i was scared to write a user authentication option because you know everyone talks about you know infosec and trying to secure your web apps as strongly as possible and how there's always you know loopholes and bugs and you know exploits and stuff like that and so this whole user authentication topic was very intimidating to me the second reason that it was really tough for me is because everyone made it look so easy i would watch tutorials where we'd get through the user authentication section in about 10 minutes and i was left just scratching my head because i had no idea what had just happened i had copied the code in the tutorial but i had no idea what was going on behind the scenes in this tutorial i want to solve both of those problems so with the security side of things this all gets easier when you realize that you know when you're first building your apps the the prototype version it's not important to you know secure your app on a grand scale like a corporation would have to the methods i'm going to teach within this course are perfect for someone who's just trying to get a basic auth strategy implemented and put it into their you know prototype app or even a small scale business it's going to be secure enough for something like that and on the second point in terms of understanding what's going on behind the scenes i really hope that this tutorial is the most in-depth user authentication tutorial that you have ever seen as you can see by the length of this video it is very long and the reason being is not because it takes us you know this many hours to implement authentication but because it takes us this many hours to understand all of the different components that go into an authentication scheme for example if we're using passport js we have to understand middlewares in express because passport.js is a middleware and not only that but it's actually a little bit more complex middleware than you're probably using on a normal basis on the actual authentication side of things there's a ton of topics that we don't really you know associate with user authentication when we're just trying to implement it for example do we understand cookies in the browser do we understand http headers that allow us to set those cookies do you understand how a json web token works what's in the payload of that json web token and furthermore in the payload of that json web token we're using techniques like hashing algorithms and cryptography these are not simple topics there are universities that have entire curriculums on just cryptography and concepts associated with it so as you can imagine talking through all of these things is going to take some time but i can assure you i'm going to walk you from point a to point b and i'm not going to leave you hanging on any part of this tutorial i genuinely hope that you enjoy it as much as i enjoyed making it and at this point i think we're ready to jump in today we're going to be talking about how you can implement user authentication in your web applications using node.js express.js and passport.js and we're first going to kind of jump into what are your authentication options in general i know that's a question that i had for a long time you know what do we have i hear stuff about jwt username and password and then you've got all this other stuff like oauth and even some custom strategies that you can use to authenticate your users so we'll go through that then we'll talk a little bit about the passport js framework what it is what kind of structure does it use to authenticate users into the apps and then what are some of the different strategies that you can use within it and then finally we'll actually go into the implementation of the passport local strategy in the passport jwt strategy although we'll talk about which strategies we might use in different situations both of these strategies are going to be really good for anyone who is just trying to get their app off the ground and their primary focus is not necessarily on authentication but they actually need authentication to get it off the ground so these are kind of like the the bare bones um most basic way to authenticate users into an application and it's going to be great for you know individuals small teams startups anyone that is building their application from scratch there are a few prerequisites for this tutorial series i've pretty much assumed that you already know the basics of coding within the node.js ecosystem so that means you know you have a pretty good understanding of node.js modules and package.jsons all of that kind of stuff as well as things like the express framework also things like asynchronous programming so promises and callbacks hopefully you're at least a little bit familiar with all of the topics here on the screen if not you can still get through the tutorial but i would highly suggest kind of brushing up on anything that you're not you don't have a very basic understanding of the first thing that i want to cover is what are your authentication options here before we get into any coding it's pretty important to take a look at what's available to us and deciding what is my use case and what's going to be best for that use case so on the screen i've laid out all of the authentication options that you might find if you are in the node.js ecosystem or any other ecosystem for that matter and they are listed from least complex to most complex but that does not mean that the least complex option is the worst option it just means that as you kind of move up that chain it's going to require a little bit more understanding more pieces that you have to understand to implement the strategy itself in the scope of this tutorial series we're just going to be sticking with the left two so the session based authentication aka the passport local strategy and the json web token or jwt authentication or aka the passport jwt strategy now you also have a little bit more complex authentication that you'll see especially if you're trying to use um a large api like maybe the youtube api or any google api um even github's api these big companies rely on oauth it's just a protocol to give different access rights to users trying to access resources within their api so you'll kind of get the gist of what that is as we get into the jwt authentication but i'm going to stay away from completely diving into the oauth although we're not going to actually get into the the coding implementation of solutions like oauth or even custom solutions it's definitely important to at least touch on it so what oauth is all about it's it's just a protocol and i know that can get pretty confusing when you have um software as a service providers such as auth0 and octa among others that actually provide this oauth protocol as a service so you it's really confusing if you look at those companies you know namely one that's named off zero which sounds like a protocol it gets really jumbled in your head like what's the protocol what's the company you know how is all this working so really what oauth what the oauth protocol aims to do is separate out the two components of we'll call user authentication i got to be careful with the terminology here because there's a big difference between authorization and authentication so on the left with the jwts and the local logins the session based authentication that is all about knowing who the user is and that is what we would call authentication now on the other side of things if you have seen things like social logins like sign in with google or sign in with facebook that's a little bit more about authorization so that's kind of it's not as much who who we're talking about but instead who has access to what resources so in other words you'll get into things like scopes you know what does this particular subject or user have authorization to access does it have authorization to make just get requests against the api or does it also have authorization to edit certain resources within the api so as you might guess using the oauth protocol and you'll also hear things like open id connect is closely related that is going to be used with these bigger services where you know maybe one company such as google allows users that have varying authorizations to access the api in the same way so if i or you wanted to access resources from say google's youtube data api so if we wanted to get youtube analytics or something like that we don't have authorization to do certain things within that api and that is defined by the scopes that we are basically provided in our access token that's related to the oauth protocol now i know all that sounds very complex and it's definitely not something that you can even begin to understand completely in just a few minutes but i did want to talk about that um and kind of just mention what it is and why we're not going to get into all the details of it i think we have plenty on our plate with the session based authentication and the jwt based authentication to even start talking about that so those are your options we're going to stick with the two on the left the least complex ones and probably the most common implementations that you'll see for startups and people who are just trying to get their application off the ground and worry about the complex authentication of it a little bit later down the road when they have either more resources more money or both that can actually spend the time to implement something a little bit more complex like the oauth protocol to wrap up this introductory video i wanted to give a brief overview of what the passport.js framework is and the reason being is we're actually going to be implementing two different strategies within the passport framework but that just basically means that we have two different middlewares that are connecting into the bigger passport js middleware so you might ask what is a middleware for those that are not familiar what middlewares are in express or are just a little bit fuzzy on how they work i have created a video that will be included in this playlist so that you can brush up on that and get yourself up to speed but basically all that passport js is is a middleware that integrates within your express.js application and handles all of the authentication logic using the specific strategy that you choose to plug into the passport.js framework now the strategies that are included if we go to passport js we can go to the home page and see that there are plenty of different strategies here so we can do anything from the passport local and passport jwt like we're doing and we can also do something a lot more complex you can see that we have stuff like the passport oauth 2 which is what we just talked about or even you know something more specific passport instagram we can use the instagram login to authenticate our and delegate access to our users so there's a lot of different strategies and all of these strategies have been created by independent developers that basically say okay here's the passport.js framework it's just a middleware and it allows me to kind of use that framework as a starting point and then we can just build in the the specific pieces of authentication in our own middleware which we call a strategy so in summary passport js is just a framework that is a middleware that also allows individual developers to develop other middlewares called strategies that connect in with this bigger middleware that we call the passport.js framework and then all of that gets wrapped up into a bundle and put into your express app and it works seamlessly with your express routes we'll see in a lot more detail how each of these strategies the local and jwt strategy work as we go through the series but it is important to just understand the basics of what this is if i had to sum up the code logic of passport.js in a few sentences it would basically be this so passport.js is a middleware as we just talked about and on every http request that a user calls to our express server the passport framework is going to first pick up okay what strategy are we using here and then it will use that strategy to say hey is that user that just requested that resource authenticated if that user is authenticated then passport is going to let that user access the resource it's going to you know go into the express route if that user is not authenticated based on the strategy we're using then passport is going to return a 401 http status which is basically the unauthorized status so that's kind of passport.js in a nutshell again it's going to get a lot easier as we see the actual code flow of what's going on with this middleware congratulations you made it through the first part of this super long tutorial on user authentication now we talked about all the different options here and we're not going to be covering some of those delegated authentication options but there's plenty to cover with the other ones and particularly with the passport local authentication strategy where we're going to be using the express session middleware having a solid understanding of http headers and http cookies is going to be absolutely essential as a web developer you go on a bunch of different sites and you click that accept button when they say you know we use cookies on this website but you actually know what that means i think you're going to find this section interesting but let's go ahead and dive in what is an http header i think it's something that we know in the back of our heads kind of what it is especially if we program a lot of web apps but it's also something that we don't spend a lot of time trying to learn and we frankly don't need to learn a whole lot about them that said we do need to specifically learn about an http header called the set cookie and the cookie header in order to understand how server-side sessions work and kind of interact with the browser so if we come to google.com right here i always use this as an example just because it's pretty arbitrary spot if you open up your developer console here in google chrome and go to the network tab you'll see that it is pretty much empty right now but if we click refresh on the google search and we're basically doing a get request to google.com and you'll see a bunch of stuff loading a lot of these are the resources that run the page or scripts but at the top you see this www.google.com if we click on this you'll see that there are some headers here and you'll see that the headers come in three basic categories first you have the general headers then you have the response headers and finally the request headers what we're specifically interested in in this case to understand what a cookie is and how it works is the request and the response headers but we can also kind of explore the rest you can go on to mdn is a great place to look and you can see there's you know a link to all sorts of different headers so we can go down here into security and these are all the different security headers that you could set in either the general response or request headers now let's take a step back and really think about what just happened when we pressed the refresh button in our browser to load google.com if you think about it a http client could be anything from an iot device someone like me sitting at my desk or at a coffee shop you could think of it as just a laptop or a phone pretty much anything that connects to the internet is considered an http client now on the other side of things is all of the http servers and those servers google in this case is going to house the information that the clients want to access or update or do other operations on so in our case what we did was do a get request to google.com in other words we want the resources at that web page so if you look at the headers here in the chrome tools you'll see as we talked about we have these three categories so let's just go ahead and walk through each of them and see what was relevant to our request so in the the first one the general headers these can be either request or response related they're just kind of general metadata about the request such as what is the url that we're requesting what type of method are we using so this is a get request those were both probably those are in the request side of things now if we go to the response side of things you'll see that we got a status code of 200 which means that we requested data from google and it sent back the data successfully so you can see that we have several you know things that kind of mix between the request and response now in our particular situation when we searched google we formed or we didn't form but the browser that we were using created a request header which is basically instructions for the server in what data you know the request wants so i'm the client here sitting at my computer so the the browser on my behalf is going to say hey whoever i'm trying to get these resources from i'm going to put in the request headers what kind of data i accept so you can see that we have things like the accept encoding except language and then just the accept http header and we're basically saying that we accept html we accept xml and a couple other different options but you can just think of this request header as the instructions for the server that you're requesting resources from or trying to modify what type of data that the client myself will accept in the browser is not the only thing that you can put in this request header you can put all sorts of other things you see there's a cookie in here we'll talk about that in a few minutes but you also have things like the user agent tells us what browser is requesting this data and then if again you can go to the mdn site and look at a broad variety of different things that you could put in the request header so you can click on the request context and you can kind of see some of the things that you can put in that so we know that http headers are basically metadata about our our http request so we can also do that on the response which would be set by the server which in this case is google so one of google's servers whichever gave us the content that we're viewing on the web right now is going to set these response headers and these response headers are going to give additional instructions to the client that requested the data in the first place so you can go through a couple of these and see you can see the content type so if you remember in the request header our you know the client which is the browser i'm sitting in and using right now said i only accept a certain type of data and then the response is going to say okay you only accept that type of data here's the data and here is what type it is so this is useful if you know we're trying to figure out how to display that data in the browser of course there are other things that that you'll see here but i want to direct your attention to something very relevant to what we're talking about right now which is the set cookie header now you can see that the set cookie header is basically giving key value pairs and you can see you know right here it says expires equals friday the 31st of january 2020 at this specific time so you might be asking well there's a cookie header in the request object and there was a cookie header in the response object how can that be what is the difference between the two and how do they work over the next few minutes i'm going to walk you through exactly how the set cookie and the cookie headers kind of work together and then in another video we'll actually talk about how this all plays into what we call a server-side session the easiest way to understand what a cookie is and how it works is to remember that http protocol is a stateless protocol in other words it's going to constantly forget what the user has done on the site unless we have a way to remember that so in other words if we go to google let's just imagine the scenario we go to google and we sign in to google and we'll just assume they actually probably don't use this method but we'll just assume that they're using cookies and server side sessions to authenticate us so what happens is google the server is going to say okay the client that just you know signed in gave us valid credentials and so what we want to do is you know send something back that allows the browser to remember that this user has logged in if we don't have anything like cookies or local storage probably more modern way to do it if we don't have these types of persistent storage then every time we refresh the page our the state that we had previously where google said okay we logged you in is going to have to be redone so every time you refresh the page you're going to have to enter your login credentials which of course is a terrible user experience and any site that does that is going to lose their users immediately because they're going to get completely tired of typing in their login credentials so this is where the set cookie and cookie headers come in so let's do a little experiment here and i know this is not a perfect example but i think it will do for what we're trying to accomplish here so let's click on the application and open up cookies for google you'll see that there's all sorts of cookies you know google knows everything about everyone so we can just go ahead and delete these it doesn't hurt anything to delete all these cookies so at the moment our browser has no cookie set whatsoever so we can come back to the network tab and let's go ahead and refresh the page once more you'll see that we had this google.com here and we can open up the response and request headers and you'll see that the request headers it's pretty much the same as what we had looked at before and then in the response headers we once again have these set cookie headers and what these are doing is basically saying okay or the the google server is saying okay client i want to set this information about you so we'll just assume maybe we just logged in and google wants to tell the browser that i the client is logged in and we don't need to re-authenticate every single time that we've refreshed the page so what happens here is we have these set cookie headers and let's just pick a very specific key value pair here just to see what's actually happening so let's get a pretty easy one we'll just say the 1p jar it gives us a date of 2020 1-21 i'm not exactly sure what that means but keep this in mind this is what we're going to be looking for so if you go to the application you'll see that now these are set in the cookies field so we have the 1p jar and then the value that was set in this response header so now what our browser will do is it says okay now we have a cookie set so every request that we make within this domain so google.com i want to attach those cookies that were set based on this set cookie http header in the response header so what's going to happen is when we press refresh again it's going to actually put these cookies in the request headers so right here in this cookie request header we should see something like these set cookies that google the server had put into our browser so let's click refresh once more go to thegoogle.com and look at the request headers and you can see that now this cookie header right here has that 1p underscore jar cookie key value pair so just to recap what just happened we had a client me refreshing or doing a get request against google.com and whatever google server that gave me that data said i want to set a cookie in this client's browser so it uses the response header to do that it assigns these values in the set cookie header and then when we reload the page our google chrome browser or any browser for that matter is going to say okay my default behavior is this is to look up what cookies are currently set in my browser and i'm going to attach those cookies to every single request for the domain context that it is applicable to which is google.com in this matter if you really think about it this method of setting and then the browser just attaching the cookie to each request is a really powerful thing when it comes to user authentication you could say hey maybe my server can do some sort of logic and say okay is that user valid invalid did they give me the right password if they authenticated correctly then i do the set cookie header in the response object and then now the user or the client that is using my web application now has that cookie that says yes this user has already been authenticated and then the browser every time it reloads will attach that cookie and you don't have to re-log in that user now the real question is how long do we keep that user logged in and that's a totally arbitrary question but we can do that with the expires piece of this set cookie http header if we come over to the network tab and look at the response headers from google you'll see that there's the cookie that's being set so 1p jar it looks like this is actually set on every get request to google but you'll notice that it has an expires piece to it so this is what tells the browser how long to store that cookie key value pair within the the client so we can actually go through this exercise on our own using some simple javascript to see exactly how it's working so let's go to the console and type in a few quick commands so first we're going to create a new date which is going to represent the date and time right when i click enter so we'll say enter and then we're going to say we want to set the time 20 seconds later so let's do that and then finally let's set a cookie to the browser with the an expires header at that time so we really only have a few seconds but you can see that we have a custom cookie that's going to be there for about 20 seconds so if we reload right now it shows that it's gone so let's go ahead and do that one more time a little bit quicker this time so here's our cookie go over to application you'll see that we have the custom cookie and every time we refresh the browser you're going to see that cookie is going to stay there but then in about 20 seconds which is coming up here in a few seconds i think you'll see that that cookie actually will drop off and it will no longer be attached to the http request so if we refresh you'll see it's gone and that user will say that that was a cookie that gave a user or the client's authentication status that's gone the user has to re-login now obviously you're not going to set a cookie to last for 20 seconds you might more realistically say that you want the cookie to last for two weeks and that is a really powerful way to keep some sort of persistent state within the browser and not require users to log in every time they refresh the page the next part of this tutorial is all about express middleware in order for us to implement the passport local strategy which utilizes express session we're going to have to understand middleware and that's because both passport.js and express session are both middlewares if you don't understand this concept really well then both of those libraries are going to be confusing to you furthermore i'd consider this one of the most essential topics of programming in the express framework while the official express documentation does cover express middlewares in some capacity and it's relatively clear when i was a beginner i'd never understood it fully and even to the point you know two years into my programming journey i still did not have a solid grasp on this express middleware after learning it in depth for the first time i can really confidently say that this is going to be one of the most important lessons that you learn you know as a node.js developer using that express framework so without further ado let's dive into this express middleware overview when you start out using express.js as a framework it's an entirely middleware based framework but generally when you first learn it you're just copying in you know the different pieces and you know that there's kind of something working behind the scenes but you don't know exactly how it's working so in this video we're going to talk about how exactly does this middleware work and how does the request response and next or callback object as well as even the air object work in express application in order to do this we need to spin up a really quick basic application um what i'm working in here again this is part of the passport.js series so i'm in the repository that we're using for that but don't worry this is just a basic express app so we first need to require in express i've already installed this with npm so i don't need to do that and then we say app equals express and then we just say app.listen on port 3000 so right there is the most basic form of an express server that you can spin up and if we were to visit localhost 3000 we're not going to get anything but if we just throw in one simple route app.get and then we pass in the request response and next objects and then we send some sort of data we can now run this in the browser so let's use nodemon which is going to automatically update on every time i save and we'll run app.js so we're running app.js it's listening on port 3000 and it'll be listening on localhost so if we go to the browser and visit localhost 3000 port 3000 you should see the hello world so we have a basic server running and that's all we need to do to start understanding how middleware works in express so we come back to the code here and the first thing that you need to understand is this right here so with our app.get this is just a route that we've established in our express application we are passing in a route string and a callback function usually you'll see it in this syntax but to better understand it we can just basically write a function where we say request response and next now to make this even more transparent what i'm going to do is name these custom properties so normally you're going to just see it r r e q r e s for request and response and then next but you don't need to call them that it's just always going to be passed in you can call them whatever you want so we can say request object response object and callback function so well actually we probably shouldn't call it the callback function we should say maybe next middleware or something like that because the purpose of this last parameter is if we call it as a function it will pass it to the next middleware in the chain so we'll understand that a little bit better in a second but first let's go ahead and write our function so we need to give it a function name so we'll just say standard express callback and we pass in these three parameters and then we can say res.send and hello world so basically we've got the same exact thing that we had below in the app.git route to implement this let's just delete what we wrote here and let's just pass in our standard express callback so we've defined it up here we know that express as a framework is going to pass in these three parameters and so there we can just throw it into our route and click save and then if we come to the browser again if we refresh the page it's going to say res is not defined and the reason being is because i was dumb and forgot to update that so now that we're passing in request and response object we obviously need to also use that in the body of the function so that was just a silly mistake but now if we come to the browser and do it again we should get hello world as we expected so that's the most basic way that an express route works and we're using this function that we had defined so just like we could define this function we can also define other functions which we call middleware so the way that we do that is pretty simple we'll just say middleware one and what we need to do is pass in those same three objects that we were using before so the request object response object in next middleware or whatever you want to call them in this case i'll just say record req res and next like you would normally see it and then we can do whatever we want in this middleware so maybe we'll just say console.log i am a middleware and then in this one this is the standard express callback this is where we return some data we can say console.log i am the standard express function so if we just define that function up here and we don't do anything with it it's not going to do anything obviously but we can pass that into our route to make it work for us so let's pass in the middleware one and a comma so you can see that express as a framework allows you to pass in pretty much as many parameters to the different route functions as you want let's go ahead and save this real quick um let me open up the terminal a little bit more so that we can see what's going on and let's go to the browser and visit that same route we'll go ahead and click refresh here and you're gonna see that this is gonna just keep loading it's not gonna ever return us data and if we were to you know copy this into a new tab and click enter it's not gonna actually return us anything and that brings up a very good point with express middleware if we come back to our code that we wrote you'll notice that in this middleware that we passed into our route that we were visiting we haven't actually called this next parameter so in the express framework the next parameter is going to be actually a function and all we have to do is call it at the bottom of our middleware and what that's going to do is it's going to say for this route right here we first run middleware middleware number one or middleware one and in middleware one we call the next function that was passed in as a parameter by default by express and when we call that it's going to basically say okay now we get to go to the next middleware or in this case it's the last one it's the standard express callback so if we don't put that next function and call it it's never going to get to this last function and we're not going to ever return any data so now that we've called this next function we should be able to go back to the browser and see a response so if we refresh we'll see that it should return hello world and you see that it did return it and if we come back to our code again you'll see in the console that we printed i actually ran this route twice so we printed i am a middleware and then i am the standard express function and the order of this is very important because first in the route we run this middleware and then we run the standard express callback so first we're going to console.log i am a middleware second we're going to console.log i am an express function so that is the basics of how this middleware works but we also have a few other things to understand so what we've been using so far by passing the middleware into the route itself is a route specific middleware now this is kind of i just think of it this way i don't know if it's the exact term that you would use but i call this a route specific middleware but you also can have global middleware so if i took this out of the route and i came up to the top right under the definition for the app and i say app.use what this function built into express expects is a function or a middleware that it can execute so in this case i'm going to just take middleware number one or middleware one and say app.use middleware1 so what's going to happen is the express app is going to initialize and then it's going to initialize the middleware one so let's go ahead and see what happens in the console when we do this so i'll let me make sure i got this right so we've got our middleware defined here we call next and we're initializing it with the app.use up here so let's save that and you'll see that nothing has happened in the console yet you might expect since we did this outside of a route that it would just automatically print i am a middleware and go to the next something but that's not the case when we say app.use it's basically just adding a piece to that chain of functions or middlewares that we're going to be calling so once again we have to come back to google chrome and execute this git route so let's enter and so it loads correctly and then if we come back to the code again now you're going to see i am a middleware and i am the standard express function so what just happened here well first off we defined that this is the first middleware that we want to use in all of our routes it's not just specific to this particular route it's going to happen in any route that we define within our application next we have the standard express callback which is in this specific route so first the route's going to call middleware 1 then it's going to com call whatever we had defined as the callback to that route so the order of the middleware that we define in the scope whether it's a global or a route specific middleware really matters so let's go ahead and see what happens if we switch up the order of the middleware and maybe even add another middleware into this equation so let's say we have another middleware called middleware 2 and again we pass in the default objects that we are provided by or provided with by the express framework and we'll say console.log i am middleware number two and maybe we should just update this one up here to number one so we've got middleware number one and middleware number two and what i'm going to do is say app.use middleware to okay so we are using two middlewares and then we have the standard express callback which at this point i'm just going to go ahead and put it in a form that we're used to seeing so we'll just use request res and next this is what you'll see in most tutorials so i want to keep it consistent so let's copy that in there delete the function declaration and then of course since we changed the name of the parameter we need to also change the name of the object that we're using to send the data all right so let's just quickly recap what we got we have one route in our application which has a very standard syntax all we're doing is we're sending back an h1 tag with hello world in it so far in this route we haven't defined any route specific middleware but we have defined global middleware so let's see what happens go ahead and kind of make your guess as to what's going to happen here but if i had to guess we're probably going to print i middleware number one and then i am middleware number two when we call that route and then finally we'll you know console.log i am the standard express function all right so we've saved it let's go back to the browser click refresh and i don't know why it hangs sometimes here try it again maybe we have some sort of air did a little bit of refactoring nope it was doing just fine we've got all the things that we expected so if you could guess what's actually happening here is again we forgot to call the next function in the middleware 2 so it never reached this final function save it once more come to the browser once more and refresh we should get a good response come back to the code and you'll see i am middleware number one i am middleware number two and i am the standard express function all right so everything is as expected and now is where the real you know understanding comes into play because oftentimes when we're using an express application we've got all sorts of middleware working together in most express applications you're going to have several app.use statements so you might say app.use course cross-origin resource sharing that's a pretty common one or app.use body parser and then whatever the configuration for that was so you might have up to like 10 15 even 20 different middlewares that you are adding to your express application and so it's really important to understand that the order that we put these in matters so if we were to put middleware 1 after middleware 2 all we did was change the order of those statements if we save and then go to the browser and call that route you're going to notice that when we come back to the code we now have things out of order so we have i am middleware number two coming before number one so that's really important to understand and then of course if you put one of these within the route itself it affects the order as well so let's add one more middleware to this equation and it's just let's just copy this do the same thing so we'll call this one number three number three right there and then we're gonna take middleware number three and put it in the route itself so let's copy it right there give it a comma and now what's going to happen is we should have middleware 2 called first then middleware 1 then it goes into the route specific middleware so then we have middleware three and then finally this last function which we technically could call middleware as well so let's see if that worked we should have middleware two one then three so let's go to the browser run the route come back to our code and you see that we have two one and three exactly how we defined it two 1 and then the route specific middleware there are two more things that i want to talk about when covering the topic of express middleware and one of those is air handling because an air handler in express is also just another middleware but it's actually a special type of middleware so in order to define an air handling middleware what we have to do is define a function with a fourth parameter so let's go ahead and define a function called air handler and you'll see that in this app i've kind of simplified it a little bit so we only have one middleware we got rid of all the rest of the stuff but this time we're going to pass in an error parameter then the request res and next parameters so this is how we define an error handling function and we can you know this is basically a middleware so we can do as many error handlers as we want so if we wanted to catch specific types of errors so we say if air dot status equals something then we want to you know handle it in this one and then we could come down and do another error handler and say this is error handler number two and if error air dot status is number two number one you kind of get the point we can define as many of these as we want and handle different types of errors depending on the application that we're doing but what is going to happen here is this error parameter will be populated with an error if it exists so what we can do is we can say something like maybe instead of throwing the air explicitly we'll say if there's an error what we can do is res.send and we can say there was an error please try again so something more friendly than a default error that you would you might get in the browser that would crash the entire application so let's go ahead and comment this out for one second and see what happens if we don't have an air handler so right now we don't have an air handler and maybe in this middleware up here instead of console logging i'm a middleware and continuing to the next we can say that we have an air object which is a new node.js air so i am an air and what we can do with this is we can pass it in the next function so normally we just call next and it goes to the next middleware this case we're going to actually pass the air object so this would be common you know this would be more common in a scenario where maybe our middleware was doing something complex we were making a database call and we were just catching any errors that happened with the database something that we cannot control so we always want to catch these errors and if we do catch them we want to pass them in the next function so when we do that we're going to go back to the browser real quick and if we refresh this it's going to say i am an heir and you're going to get the entire stack trace which you don't want because this is where the users will see what's going on and you obviously don't want to send this type of error to a user you want to handle it in a more graceful way and not to mention if we do it like this you can see down in the console or in the terminal that we've crashed our application so if this is running out on a server somewhere and we don't know that this has happened our application could be down for hours without us even knowing so it's really really important that we use an error handler in our express application to catch these errors and handle them gracefully without crashing the express application so again air handler just another middleware with one extra parameter so let's uncomment this air handler function and normally you'd set this up a little bit more complex than what i've done but we'll just go with this for now just to demonstrate the point so we've got the error handler and so now we're going to say app.use air handler now we'll go to the browser again we'll refresh and now we're getting a more friendly error message now that we've defined this error handler let's go ahead and put it in as a middleware so let's just say app.use air handler and click save now let's come back to the browser real quick and refresh you're going to see this dreaded error message in the browser you're going to ask yourself why we defined our air handling middleware so we should have a friendly message here well what's happening is we have done this out of order and like i said earlier in this video the order that you put express middleware in matters and in this case we need to throw our air handler at the very end of our app so after all of our routes and all of our middleware we need to put our air handler and the reason being is because if there is an air in any of our middlewares or our routes which are basically just middlewares then the air is going to be passed directly to the final air handler so in this case we have the air happening up in our first middleware so what's going to happen when we say next and then air express is going to pick up on this and say oh there's an error let's send it past you know let's skip the route here we don't need to go into this we need to just go straight to the air handler and handle it appropriately so this is kind of how express middleware works and you can see that this will more gracefully handle the air if we come back to the browser and refresh now we're getting a much used more user-friendly message in many cases you might do something instead of actually sending data like this we could just say res.json and then we could say air and then our front end application could handle this error on the front end rather than you know the server handling it alright so we have covered how to handle errors using air handling middleware and finally the last thing that i think is important to cover when it comes to express middleware is the fact that we can actually mutate or kind of append different properties and objects and functions to these parameters that we're passing through each of the middlewares so what we could do here is let's once again let's get rid of the error in this middleware let's also get rid of the console.log we just want to have a basic middleware let's call this number one again then let's say number two and let's put these in as global middlewares so here's middleware one and two so first our route's going to call middleware one then two and then the actual callback for the route so to demonstrate this let's go ahead come up to middleware one and say something like request dot custom property equals 100. all right so we just created a variable that is attached to the request object now since we're passing since express as a framework passes this request and response object through each of the middlewares it will actually be available to us in later middlewares so what we can do is we can say we define it up in middleware 1 then in middleware 2 we say console.log the custom property value is and then let's put in that custom property so in middleware number two we should print the custom property value is 100 but then we want to reassign it so let's say custom property equals 600 just a random number and then finally down in our routes we'll say the value is and then we'll put in request dot custom property and in this case it's probably going to print or not probably it will print 600 because we have modified the property in middleware number two so let's save that go to the browser and see what we get so we see we see that the value is 600 and that is because we set it in our second middleware which was the last middleware that modified that property now you might be asking what is the point of this why did you show me that well the reason being is because it helps you to understand how a lot of the middlewares that we use on a daily basis in express are actually working so if you're following along this series the passport.js series for user authentication this is exactly how passport js which is in express middleware is going to keep track of users whether they're authenticated or not they the passport middleware is going to take that request object and it's going to actually append different properties to it and also if you watched the previous video in this series on the express sessions middleware you also know that the request.session object is where the session is stored so you can see how powerful this is and how we can actually store data within the request object and you know each of our middlewares can have access to that data even if they come way after the middleware that first modified the data so that's just kind of a brief explainer of how middleware works in express and how air handling middleware works in express hopefully it kind of um broadens your express horizons a little bit i know when i first learned it it did um and it made me a lot better express developer i now write middleware for all of my applications to do just ad hoc things anywhere from you know authentication guards so maybe we're checking a value of a user that we've received maybe we're checking if they have administrative rights and we use a middleware to do that so the middleware would basically look up the user in the database check the admin property if the admin property is true then we pass it to the next middleware if it's false then we might return something like 401 or 403 unauthorized http statuses all right after this last section on express middleware we are now set up to really understand the express session library when you're implementing the passport local strategy it uses express session under the hood which can be extremely confusing and when you read through the passport documentation it doesn't make it abundantly clear that this is happening in this section i'm going to teach you exactly how this express session middleware is working behind the scenes kind of independent of the passport js middleware itself and then we're going to talk a little bit more about how that express session is being looped in to our passport authentication middleware now the really cool thing about this section is that learning the express session middleware is not only going to help you implement a passport local strategy but it can also be really useful for other purposes within your web app well state management is often handled on the front end with frameworks like angular vue.js or react there is the possibility of handling some sort of state or application state on the back end in the form of a session that is what the express session library aims to do but enough talk let's dive in and understand all about this library so in this case we're going to be looking at a very simple express app and i'm going to take you through how the session is working how the cookies kind of work with the session and some of the configuration that you have to do to set up the express session middleware what i've got open right now is the repository that goes along with this passport.js tutorial series and we just have a folder for little one-off tutorials like this one i've already created an application which is an express application and i'm just going to quickly walk you through what i've done and then we'll go through what's actually happening what are some of these configuration options so the first thing that i've done i've already installed my dependencies we've got express mongoose for the database and then express session which is an npm module we then have something called connect which we'll get to in a few minutes it's what we're going to actually use for the session store then of course we set up our express app pretty familiar to most people we connect to our database right here so i'm just using a completely unauthenticated localhost database i've got that running in the background already so if you're trying to follow along be sure that you get the mongodb server or that process running before you try to run this app so we're just going to use the tutorial database and then these options here are just set because when you run the application is going to complain about it if you don't put these so that is all we've got and we create the connection right here so the connection represents um our database connection and then down here we have some pretty familiar json and url encoded middleware which is going to allow the express server to parse the different request types so that just pertains to the type of responses that we're getting in on the server and then finally we have things related to the session itself which we're going to dive in a little bit deeper and at the bottom we've just got we're listening on localhost 3000 and we have one simple route for the home page just says hello world sessions so that is our app this is the only file we're working with and so it should be pretty straightforward like i said this tutorial is not an express tutorial and i assume that you already have a decent understanding of how the express framework works i'm trying to stick primarily to how the express session middleware works so if you don't understand how express works or how middleware works be sure to check out some of my other videos or just read some of the documentation online before we get into any of the configuration and understanding how the express session works we need to answer the question what is the difference between a session and a cookie you'll see that in the configuration i've got a cookie set and in a previous video that i did again link is in the description um we talked about what a cookie was so basically a session in a cookie are different in the places that their data is stored so a cookie has its data stored in the browser and that browser is going to attach that cookie key value pair to every http request that it does a session on the other hand is going to be stored on the server side so when i say server side just the express js application and so this express session is going to store a little bit bigger types of data so in a cookie you can't put a whole lot of data and it gets very tedious if we're constantly adding more and more data to the cookie that we're attaching to each request so it would make sense to put that in a server-side session where we can store much larger amounts of data in addition a server-side session is advantageous because with a cookie we cannot store any sort of user credentials or secret information if we did that then a hacker could easily get a hold of that information and steal personal data so the benefit of a session is basically the fact that we have it on our server side and we're actually authenticating into the session with a secret key so with that said that is the main difference between a cookie and a session i want you to keep that in mind as we're talking about the two in this video now that that's covered we have some time to get into the actual code and configuration of an express session and then i'm going to show you kind of how it works in real time so what we've got on the screen right now is the express session documentation it's just an npm module a pretty popular one at that and you can see on npmjs.com there's all the documentation that you would need to learn how to use this but i'll just point you towards a few of the common things that you'll see first off of course we require in the express session and then these options right here are what are going to be included in that options object so if you look at the code here you'll see that for our session we're saying app.use so that's just we want to use the session middleware and then we've passed into the session middleware an object right here which represents our options so if we go back to the documentation really quickly you'll see that all of these options are documented right here under the options section now the one thing that i wanted to point out you get through the options that's great fine but then you get to the bottom somewhere down here and it talks about a session store implementation so if you're unfamiliar with what that is it's basically deciding what um persistent memory are we going to store our sessions in if you remember from a few minutes ago i said that a session is used to store information about a particular user moving throughout the browser or a client and so we can potentially get up to a decent amount of information and therefore in a production environment it would be useful to have an actual database storing that information now by default the express session middleware just comes with its own implementation of a session store but it's not using a database it's just using in memory or memory that's local to your application and it's not going to be a scalable solution so what we need to do is set up an actual session store which is a fancy way of saying we need to connect our database to the express session middleware so there's going to be a lot of options for what session stores we can use and they're documented here at the bottom the one that we're using particularly is the connect session store which is probably one of the most popular ones and it allows us right here to connect to the mongodb database that we have running in our express app so let's go back to our app real quick and see what i mean so to do this session store to connect it up we first have to have our database connection so we talked about this a few minutes ago here's our connection we're just using a tutorial database on localhost nothing you know you'd obviously want to change this if you're in production but we've got this running on my computer and i can actually come down to the terminal here and run the shell and you'll see that we can show dbs and you'll see that we have a tutorial db set up when we connected to this database now what we want to do is we want to tell the express session middleware that we want to use that mongodb database for its session store so you'll see that that happens right here in the store option of the session middleware and so what we've done is we've passed in the session store object into this store option and the session store object is set up right here and it is basically just using that connect right here the connect package and we're configuring a few options we're saying that the connection equals the connection that we just set up and the collection that we'll be putting our sessions in is going to be called sessions pretty standard pretty standard option that we have here you can obviously customize it a little bit and if you went to the documentation of connect there's a few other options that you can set but what i want to show you is what is happening when we connect everything up so in my first terminal i will run this application so let me go to the path here and we're going to run the application so we are listening on localhost 3000 and if we come into the browser here i've got this queued up so that we currently have localhost 3000 ready to go but i have not clicked refresh yet the reason being is because i want to show you exactly what this middleware the session middleware is doing so let's first come back to our code and what we want to do is go to the shell and we want to use the tutorial database so now we've switched to the tutorial database let me clear the screen and we're going to show the collections that exist in that database when i ran the app it initialized this sessions collection in my database but if i say db.sessions.find there's going to only be a couple objects in here let me just go ahead and drop this really quick because i think i had some stuff from previously so let's just say db.sessions.drop so we dropped the database if we show the collections now there's nothing but if we were to come here and refresh the app so we're using nodemon so if we click save it's going to refresh the app we're going to go into show collections and you see again that the sessions have been established and if we say db.sessions.find we shouldn't find any documents whatsoever in this collection so we have a completely clean slate and in order to establish a new session all we have to do is make some sort of http request to our application so if i came to the browser and i clicked refresh here what's going to happen is that session middleware is going to kind of fire it's going to create a session and then what it's going to do is create a session id which is going to be stored in a cookie in this browser so like you know just like we don't have any sessions in the database yet we also don't have any cookies in the browser yet so let's go back to our code and what i'm going to do is just walk you through a few the options and then we'll finally see exactly how it's working so when we set up our session middleware we have a secret pretty self-explanatory but this secret is going to well usually it's going to be stored in an environment variable and you don't want to expose this to the public because it basically says if the secret is invalid then the session is invalid too but in this case i just put some secret just so that we can have it all in front of us then we have a couple options here resave and save uninitialized and these are just options relating to what does the session do if nothing has changed what does the session do you know if something has changed and basically tells the middleware how to react to different events in the browser you can read up on the documentation a little bit more on these options but the thing that we're interested in we already talked about the session store but what we're doing is we're setting a cookie max age so in other words like we talked about in a previous video a cookie can have an expires header and or not a header but an expires property which says after a certain amount of time the browser is going to delete the cookie and it's not going to attach to any of the requests in the future so in this case we're setting our cookie equal to one day and you can see the math that we're doing here in the comment we're basically just saying one day 24 hours in a day 60 minutes in an hour 60 seconds in a minute and a thousand milliseconds in a second and so that's the math that we're doing right here to get to a full day for that expires property so basically what's going to happen when i send an http get request to our sole route right here is the session middleware is going to initialize a session and then it's going to take that session id and set it equal to this or set the cookie equal to that session id the cookie is then going to be put in the set cookie header http header and then that is going to be in the response header it's going to go in the browser the browser is going to receive it and say oh you want me to set this cookie i'll set the cookie and now every time we refresh that cookie will be a part of that request so let's go ahead and do this we're going to visit our only route in the application and to do that we need to go to google chrome and we're going to click refresh so when we clicked well now we it did not load so let me go ahead and do that one more time we refreshed it we get our response it says hello world sessions and what you'll notice is now we have this cookie which is by default called connect dot sid in the express session middleware and we have some sort of value here which somehow corresponds to our session id so basically what's happening is the express session middleware is going to get this cookie on every request it's going to take the value of that cookie it's going to say okay look up this session id in the session store which is the database and then it's going to say is the session valid if so let's use the information from the session to either authenticate our user find out some data about our user maybe like how many times that user has visited our site anything of that sort is what's going to happen when the user loads a different route you'll also see that we have an expires property right here that says tomorrow this cookie is going to delete from the browser but for now since it's still valid it's going to attach to every single request so if we go to the network and look at that last request we'll see that in the response header this came from our express server using the express session middleware we have the setcookie header and we set the connect.sid header and we gave it an expires now in the request headers since we only did this once you won't see any cookie but if i click refresh one more time and we look at the request headers and response headers you'll see that in the request headers we have the cookie that was set previously so in other words the browser is saying okay i have a cookie that is still valid let me attach it to every ques request within this localhost domain all right so we have this cookie on every request now let's see what's happening on the back end so let's go back to our code and we're in the shell so we're looking at our database right now and we're going to type in db oh let me clear this real quick db.sessions.find and that's going to look in the sessions collection for any documents in that collection and you'll see that we have one and only one document which represents the session that we just established in the browser so you'll see that the id is right here which you can also see in that cookie that we have in the browser so let's see the first couple letters were capital a y yj so let's go back to the browser and you'll see that the cookie right here is has got that id set in it so that's how we kind of connect the back end to the front end and then let's once again come back to our code so we also have the expires header within here so we can also validate it on the back end and basically what this is going to do is every time the server gets that specific cookie with that session id attached to it it's going to come to this sessions collection in the database it's going to grab that document out of the database or the session store and it's going to get information that we have set on to that session and use it to do whatever we want to do with our application now this is great and all but what do we actually use this express session middleware for well in another video in this passport.js series you'll see how passport.js actually connects in to the express session middleware and uses the session to actually authenticate the user but since this is kind of a standalone video i'm not going to get into that all i'm going to show you before we kind of conclude is where this session is being set now we know that the cookie in the browser has the session id and we use that session id to look up the session in the database or the session store now we can also come to our routes and get information about the session so if we said console.log request dot session you'll get to see exactly what that session looks like and we can actually set properties to that session so again i'm connected using nodemon so we'll automatically refresh when we save this app so let me click control s to save you'll see that something happens here so we reset and now if we visit this route again in the browser in the console we should see the session object so let's quickly switch over to the browser we'll refresh refresh this page and then we'll come back to our code window and you'll see that our session object has been printed to the console right now all we have is a expires header and a couple other metadata properties but what we could also and this is set to the cookie object but we could also set other information so we could set something like how many visits a user has made to our page so let's go ahead and do something really simple like that in our only route that we have for this application let's just say if request dot session dot view count we want to say request dot session dot view count equals request dot session dot view count plus one or you could just do the plus plus syntax at the end you could just do something like that and be done with it but we'll be really explicit here and we'll set a value okay so if we have that property on the session we're going to increment it by one and then what we're going to do is we're going to say in the response instead of hello world we're going to say you have visited this page x amount of time so we'll use a little javascript syntax and we need to change these to backticks to get this to work and let's see we can just put in request.session.view count and now it should tell us how many times we've visited this page when we visit that page now we also have to say else because in this first occurrence we're not going to have this property set so if that does not exist then we're going to say request dot session dot view count equals one all right so we have set a property to the session object and let's go ahead and save this application and go to the browser and visit it so we're in the browser now and we will reload and it says you have visited this page one times it should be time but now every time we refresh we're going to get that number to increment because of the logic that we've put into our route so you can see how this session object could be very useful for tracking information about a specific user or client one last thing i want to show you if we go back to the code you can look it up in the database again so let's go back to and let's find that session once more you'll see we still have just one object one document in the database but now we have this little property down here so when we set the view count property on the request.session object that actually persisted in the session store or our mongodb database under the view count property so again you can see how powerful this is and you could also kind of extrapolate out and start to foreshadow how something like a passport js middleware could kind of connect into this middle this express session middleware to keep its own sort of data you came here to learn user authentication and it took us about two hours to get to the part where we're actually writing it for the first time i hope the prerequisite lessons that we just covered were really helpful to get us set up to this point and now we're ready to actually implement the passport local strategy within your web app your users are going to have the expectation that you have the option to do a username or email based authentication you have to have this because what if your user doesn't have a google account or a facebook account to use that you know other authentication option that you're offering you've got to have this most basic option for them and the passport local strategy is one way to do it equipped with our knowledge of http headers cookies the express session library and express middleware we are fully ready to jump into this strategy my goal in this video is to get the passport.js library imported into our express.js application and can start to configure it to help us with this i've set up a repository on my github that will basically give you a starter template to work from and what this is going to do is kind of eliminate all of that stuff that we don't want to focus on such as setting up a basic express application setting up a very basic database with mongodb and even setting up something like a express session which we talked about in one of the prerequisite videos for this tutorial series in this repository i've got three branches but the master branch is going to have your starter template so if you don't know how to use branches in git that's totally fine if you do want to learn more about that i actually have a full tutorial series on using git but anyways you can see if you come into github you don't have to actually know any commands to do this you just drop down and you can see that the different branches will have the final branch is kind of the final implementation um no promises that will get you know line by line character by character to the same implementation here during the video but will come very close the overall structure will be exactly the same and then we have the final all-in-one which is basically just one js file or javascript file that has everything that you need to run this with tons of comments so that you can really figure out what is going on so that's what the repository is you can go ahead and fork it or clone it whatever you want to do and then download it to your computer and once you've done that you should land to a screen like the one i've got right here and i've got open the readme which kind of gives you basic instructions on how to use it we went through most of this already so let's go ahead and close that out and take a quick tour of what's going on in this repository and then we will go into the configuration of the passport local strategy let's take a quick look at what i've got for you already set up in the template application it's pretty similar to what you probably have seen before i tried to make it a similar structure to what you might find in a lot of online express node.js tutorials so hopefully this looks a little bit familiar but anyways we start with our app.js which is going to set up our basic express app so the imports at the top let's just go through them real quick if you haven't installed them after cloning the repo just type npm install to get those installed we have express pretty straightforward mongoose which is the odm for mongodb i will mention um while we're on this line i've already got my d service running in the background so you'll have to do that when you're running this app and i i don't even know if i have this in the readme so maybe i will put that in here right now we'll just say make sure to run the mongod service before running the app locally all right so now that we got that covered just make sure that you have that running and then you should be able to run this app just fine um all right so moving on we have express session which i've covered in a separate video how this works and how to set it up so i've already implemented it here for you if you want to learn more about that go to that video again that is in the description just click on the playlist and you'll you'll find it so next up is passport this is what most of this video in the next couple videos is going to be about will require in the built-in node.js crypto library which is going to allow us to create and verify passwords we require in the routes which is the routes folder we'll get there in just a second and also we have a database configuration in the config directory now coming down we have store directly related to the express session middleware again that's another video we have this little line right here most people probably have seen it but if you haven't all this is doing is giving us access to the dot env file that we have defined over here that by default is not going to be imported when you clone this repository because it's got secret keys in it so you will need to create the dot env file and in the env file i think you only need two things you need the db string and the secret and for my case i'm just using a very simple db string i don't even have a user or a password just to keep things simple for now but in production you'd obviously want to um have a user and password in the actual database that you would connect to so and then the secret is going to be i think for the express session module so let's close that and then you can see you can actually get access to those variables anywhere within this app.js file with this syntax the process.env.variablename all right so moving on we have the express application pretty simple this is some middleware for parsing http responses most of you would probably have seen app.use bodyparser.json but i've just used the built-in express parsers because i think these actually came in a little bit recently in like a recent release i could be wrong on that um but you no longer need to use body parser all right session setup again this was covered in a different video but let's just take a very very quick look at what is going on here we have our session store which is going to say hey express session middleware i want you to use the mongodb database for the session storage and in that i want you to use the sessions table or not table but collection in that mongodb database so that's the session store down here in the configuration options for the session middleware we are telling it to use that store then we have some other options here so the secret we just talked about that that's going to help the express session middleware validate the session that it has looked up it's going to check to see if it matches that secret these two options have to do with you know how does the session treat or how does the session react when there's actually no changes in the browser you can read up about that on your own and then finally the cookie this is the this is also another separate video in this series but basically what we're doing is we're storing the session id in a cookie in the browser and this right here is just going to kind of tell the express session middleware hey i want you to it basically set an expires header um not header but an expires property of one day so this cookie will expire in one day and a new session will have to be reestablished when it does expire alright that was just a quick overview if you want more you have to check out the other video next up we have passport authentication i've just put in this basic require statement to show you where it is so it's in the config directory we'll get to that in just a moment we are using our routes so this is pretty standard in express you put your routes after the other middleware but before your air handler in this case we don't have an error handler you might want to do that for a production application finally we are listening on port 3000 localhost pretty straightforward so that is the basic app let's go ahead and look at some of the other pieces so let me save that we'll first start in the config so we have passport.js all i've done here is imported the relevant modules that we'll will need to set it up and then i've imported some database configurations uh well the connection and then the user model that we'll be um using so going straight over to the database configuration this is a pretty standard mongodb database setup we're requiring in mongoose again we got this access to the env file we're going to grab the db string from that file and we're going to create a connection with it so we pass in the string to the create connection method on the mongoose object and then we pass in these options which will just suppress any warning messages finally we have a user schema it's very simple we just have a username hash and salt you will see what the hash and salt mean a little bit later so we create a model for that user based on the schema and we export the connection so that we can use it in other files so pretty straightforward with that let's see what else we've got we have the password utils which should just have the validate password and create password functions so let's check that out and you can see that i've already kind of templated out what the functions will look like all we have to do is jump in there and actually implement them let's see if i'm missing anything else okay i've got the routes just one route file and i know there's a lot of stuff in here but really there's not much of anything we pass in the express router uh passport because we're going to actually use passport in our routes we have some past password utils we just looked at the database connection and user model and really what we're going to be doing the only thing we're going to be doing in this file is these two routes so the login and register route we're going to have to implement the logic behind these in the git routes below all i've done is create a super simple flow that will go through as we implement this passport authentication so you'll see the home page is just going to tell you to please register you click the link goes to the register page which is right here that has just a really ugly looking form that we will type a username and password into to register that will submit to our custom implemented post request up here then it will if you're successful it will redirect you i think to the login page then you will log in with your username and password which will create a post request to the login post route which we have to implement and if you successfully log in i think it will redirect you we're going to have to write this logic but it will redirect you to i believe in the i believe the login success route so it'll say you've successfully logged in then we'll try to visit a protected route and that will be right here and we're going to check if we're authenticated and let you in if you are so basically you can look at this but it's just a flow of pages that we're loading the reason i did this without using something like ejs or another temple templating language is just to keep it as simple as possible all we're doing is passing basic html and html forms and using the built-in express methods like res.send in res.redirect so hopefully that makes sense if it doesn't take a look at this for a few minutes and i know it will before we get into the actual implementation and configuration of passport i wanted to show you again i know we already touched on this in the first video just for a few minutes but i want to show you how to find the documentation for this i personally had a very difficult time finding kind of an end to end tutorial and documentation for passport and i think since all the strategies are developed by different developers there's not really you know a one size fits all documentation for it now if you go to the passport.js website you'll first find that you can click strategies and browse through all the different strategies you'll be able to go to those pages but in our case we're using the passport local strategy so if we click this we should be redirected to the passport local strategy it's going to give us some basic usage instructions so we install it we configure it with a verify function and then we can use it in the route here but that's pretty much all that it gives us there's actually a couple more steps that you need to do to use the um local strategy which is kind of weird why it's not in this on this page and if you click on the examples it goes to a 404 page i think maybe that was recent i don't know whatever the case this is actually not where you're going to want to go for documentation on the passport local strategy the passport local strategy is actually better documented in the general documentation of the passport.js middleware so if you go to documentation right here and you click username and password this is where you're going to get a little bit more verbose documentation on the passport local module so here we have the same thing install passport local but here we're getting a little bit more detailed implementation of this verify callback and how you would use the form how you would use it on the route what kind of parameters you can pass to the verify callback so this is a little bit better documentation but it still kind of misses some of the configuration that you have to do for this module so i'm going to show you exactly how to use it but you can kind of peruse the passport.js documentation you'll find a few things for example if we click on configure it's going to tell us how to configure a strategy because being a framework for the middleware passport has kind of a standardized way to integrate different strategies so on every single strategy that we use we're going to need a verify callback so in this section kind of talks about that verify callback and what the different responses are required based on how the user you know whether the user entered the correct or incorrect credentials whether we got an error message whatever the case it tells you that and then we also have documentation on the authenticate method so passport actually provides you with a built-in authenticate method on the passport object and all you need to do is provide it with the name of the strategy that you've defined and then passport figures out how to go find the verify callback that you've configured for that specific strategy i know this sounds like a lot and i know this documentation is a little bit sporadic it's not necessarily you know a b c d one two three four it's it's a little bit confusing so let's just get into the implementation and i'll do my best to kind of document the passport local strategy for you like we saw in the documentation the first thing we need to do is define the verify callback for the passport local strategy so we'll do this in the passport config file and all we need to do is comment this out the passport.use method and pass in the strategy and the verify callback so i'm just going to paste in the full thing real quick and you'll see that this looks pretty similar to what we saw in the documentation it's also going to be pretty similar to what you'll see in a lot of tutorials but i personally find this a bit confusing when we're looking at it all at once so let's go ahead and deconstruct what's going on in this configuration put it in some variables so that we know exactly what's going on all right so the first thing that we need to do is define the strategy itself so let's say strategy equals and then in this case it's going to be the new local strategy all right so that is the most basic way to create a strategy and then this strategy is going to require that verify callback so let's define that above here and the verify callback is going to take a couple parameters it's going to take a username password and done function in this case down here i just called it callback but you it doesn't really matter what you call this all you need to know is that this represents a function that you will eventually pass the results of your authentication to so those are the parameters and they will actually be populated by the passport framework based on how you implement this so we expect the username to be the value that we received from the request body of some sort of login form so if we were to create a login form type in our username and password and then make a post request to the express api that post request is going to have a username and password field and passport is going to automatically look for those two fields and grab the values of them and populate them in the verify callback now there's a little bit tricky part to this because if you don't name your username and password fields exactly this username and password the passport um framework is not going to or not the passport framework but the passport local strategy is not going to know what variable to look for so in order to prevent this we can actually define custom fields that we want passport to look in i'll show you how to include this in a few seconds but first let's just get it in a variable so we'll say custom fields is equal to an object and we'll say the username field is going to be uh you name we're just making this up making it custom so that we can see exactly how this works so our username field is you name and then our password field is just going to be something like pw so obviously these are some non-conventional ways to name the password and username fields but if we define them in our custom fields object then passport local will know where to look alright so we'll use that object in just a second but first let's come back to the verify callback so in the verify callback what we're doing is basically our own implementation of a password verification now this is where i think people get tripped up a little bit i know i did um thinking that the verify callback has to be a very specific structure and we have to use a certain database because of course the documentation online shows that we're using the mongodb database but in reality it doesn't matter what database you use and it really doesn't matter how you choose to verify the credentials all that matters is that the return values that you pass to this done callback are what passport expects so we can come in here and do whatever we want but for simplicity as we know i'm using the mongodb database so it's going to look pretty similar to what you saw in some of the examples so let's go ahead and copy this so i think we're done here with this copy paste and then we can put it right here and all we're doing is going to the mongodb database and we're looking for a user that has the username provided in this parameter so again what's going to happen we make a post request and we provide a json body with you name and password then passport as a middleware is going to look for these two fields finds them takes the value and populates these two parameters with those two values so at this time when we're executing this callback these represent the username and password so we can look up the username in the database and then just in a basic promise we are returning the user so we check if there's a user in the database you know if someone has actually registered already then or actually it's the opposite if there's not a user in the database then we're just going to return this should be updated to done to represent this done callback up here and what we're telling passport here is that no there was not an error in this operation but there was also not a user so go ahead and reject this and so passport will return i believe it's a 401 on unauthorized http status so that's the first check we need to do then um we need to check whether this is valid sorry for all these comments i had them in here before when i was writing this out so we have a variable here that says is valid and for right now we don't know how this works and this is not even a function that we've defined yet but basically what we're doing we can comment this out for well let's not comment it out yet what we're doing is we're putting the password through some sort of verification function which is going to um or we're also putting the hash in the salt stored in the user record in the database and we're verifying those two things against the password you'll see how that works in a minute but basically let's just assume that this returns true or false which it does and we say if the password if the login credentials are valid then we're going to return the callback let me update this real quick again these are just corresponding to this parameter that passport provides we're going to say nope there was no error and yep there was a user and this user was successfully authenticated based on my verification function so when we pass this to passport it's going to let us into the route and then finally if it's not valid we say nope there is no error but we did not verify this user correctly don't let them in the route and then finally we using the promise syntax we're just going to catch any of the errors that happen within the express application maybe on the database side of things and if we get an error we're just going to pass that to passport and it knows how to handle that so that is the basic verify callback and i'll show you really quickly what is actually going to happen here when we use it in a route so let me save that and come back to one of our routes so let's go down to the um the post login route so what we're going to do is include a middleware in the post login route called passport.authenticate and then in the authenticate we're going to say um the local strategy and we're going to pass in um well we can we can worry about the rest of this a little bit later all i wanted to show you here is that we're passing this middleware in the login post route and so basically what's going to happen is we make a post request to log in with our username and password and then that gets intercepted by the passport middleware and then we come in passport populates these two objects it runs this function so we're looking up the user in the database validating the credentials returning some sort of response and if we get this response right here where we populate a user then it's going to go to the next part of this function and it lets us in the route so that is the basic implementation of passport and now we're going to tie up some loose ends and make sure that it actually works and then we'll see it run live we just have a few more things we have to do to get this working um the first thing i forgot to do when we finish this up is actually complete this verify callback so we started with passport.views and then we passed in all of this stuff so we need to actually do this now um so the first thing that we need to do is let's see we have our custom fields and our verify callback so in our new local strategy we're going to pass in our custom fields and our verify callback and then we're going to say passport.use and then we're gonna pass it in that local strategy so now we actually have it configured and in app.js when we require it in somewhere um let's see where do we do this right here in the passport authentication we require in the configuration and what that's going to do is basically just take this line right here and include it in the app.js now that we've got our strategy configured we've done the bulk of the work there are a few extra things that we're going to have to put in here but i'm going to go ahead and just copy them in um and then we're going to come back to them a little bit later after we have everything working to understand them a little bit better so at the bottom of this configuration i'm just going to paste in two initializations and this is the passport.serialize user and deserialize user now this has to do with the express session and how we put a user into the session and grab a user out of the session basically what is happening is we're going to put the user id into the session and then we're going to when we want the user to come out of the session we will grab that user id that was stored there and find it in the database again we're going to come back to this so don't worry about it if you don't understand it i think this these two functions are a little bit tricky especially because there's not a whole lot of documentation around them so let's save that let me save this real quick let's come back to app.js and add in our last two lines that we're going to need before all of this is going to work so right after we require in the passport configuration we're going to say app.use passport.initialize and again what this is going to do is kind of initialize the passport middleware and um basically so that it doesn't get stale so we might be using different routes we might click to several different routes and if we don't reinitialize the passport middleware then there's a chance that hey maybe the user um maybe their session expired or something in the time that we're doing that it's just always safe to refresh the passport middleware every single time that we load a route and so that's what this is doing and then we need to put in passport.session which has to do a little bit with what we just talked about the serialize and deserialize user but um more so it has to do with the actual express session middleware so i know we talked about this a little bit earlier we also talked about it in a separate video but the express session gives us access to the request.session object and anything that we store on the request.session object inside any of the routes is going to be persisted to the database under the sessions collection so knowing this passport cleverly kind of plugs into that and bootstraps off it and uses it as a user authentication mechanism so we're going to actually go through this along with the serialize and deserialize user in a few minutes but for now let's see if we've got this working we still have a few things to do in the routes before it's going to work but let's save it and actually run the app i'm going to run this with nodemon so we have live updates so nodemon app.js and doesn't look like we have any errors at the moment so there is a chance that we have this working the first thing that we're going to have to do before the passport middleware is going to be effective is finish defining the password verification and generation functions so if you remember in the passport configuration in this verify callback that we had defined we called this method called valid password but in this module we haven't actually created this valid password function so it's not going to work as it stands right now we're going to have to go over to our password utils file and define both the valid password and the gen password functions before anything's going to work we're going to open up password utils in the lib folder and you'll see that i have basically templated out the two functions that we're going to need but to understand this i've actually put a slide together so that you can visualize which at what's actually happening with the generate and validate password functions we're going to be using the node.js crypto library to do this but before we get into the actual like what methods we're using it's better to have a conceptual understanding on the screen right now is a basic representation of how we generate and validate a password to a database now the cardinal rule here is that you're never going to store a plain text password in a database that's kind of web application 101 i think everyone is pretty familiar with that but actually figuring out how to do that is a little bit more complicated now we talked about earlier how the passport.js middleware does not give you a specific way that you need to do this it gives you a lot of freedom as to how you might generate and validate the passwords that the users are providing in the login and register forms as we go through this just note that this is not the only way that you can go through this process there are other libraries other than the node.js built-in crypto library there's also different types of logic that you can go through but i've tried to keep it as standard as possible and kind of in line with what you would call best practice so anyways what's going on here is we have two steps in the process so we have the creation of the password and the verification of the password you can think of this as the register and the login so you're sitting there behind your computer you found this cool new web app and the first thing that the web app is going to ask you to do is register you need to give them a username and a password and then maybe a couple other things like an email first last name maybe even an address or something but what's important is that you are providing that web app with a plain text password you're just typing that into a field and when the web app receives that password it is still in plain text form we can't really avoid that that's fine but what happens is we need to transform that into something that we can actually store securely in the database without worrying about some hacker you know taking over a database and grabbing all the you know users passwords in that database once the user information is stored in the database we can move on to step two which is password verification now in step two you can think of this as the login process so when the user sits behind their computer and is typing in their username and password to log into your web app that's going to be the verification step and what's going to happen is they're going to provide you with their username which you're going to take and you're going to look up that user in your database using the username or maybe an email once you find that user in the database then you're going to have access to this password hash and the salt that we stored before so you're going to pull both of those values out and along with the password the plain text password that the user just provided you you're going to put those values through the same exact hash function so you pull the salt out of the database from that user and you put in the plain text password that they just typed in and so in this case we have the same exact values for these parameters as we did when we created the hash in the beginning and we know since a hash function is always going to give you the same exact value if you put the same parameters into it we know that we can generate a password hash and compare it to the hash that we stored in the user record in the database and if those two values match then we know that we have validated this user and that they have entered the correct credentials we've got a conceptual understanding of this process so let's go ahead and code it we're going to come back to vs code again i've set up the functions in the parameters that they require right here and we're going to start with the generate password function which is the step one of the process so this password argument is going to come from the user when they type their password into the register form and then here is our implementation now i'm going to walk you through this um we're using the node.js crypto library and the first thing that we're going to do with that is generate a salt which is just a pseudorandom value and it's going to add a bit of randomness to our generation of the hash so we have the salt then we pass in the plain text password and that salt to the pb kdf2 method on the crypto library and then this last part sync just means synchronous for synchronous operation and then the 10 000 right here is going to represent how many iterations we're doing 64 is how long or how big this hash is going to be and then right here we specify which hashing function we're going to use finally we will convert this to a hexadecimal string now down here we just return those two values and we are done with this piece of the implementation to learn a little bit more about what we just did i'm going to pull up a document on google this is from the internet engineering task force and it's just basically a specification for different cryptography methods and or password-based cryptography methods and if we go down to the table of contents we can actually find the pbk specification which is what we were using from the node.js crypto library and you'll see that this is actually going to well we might actually be in the wrong spot here we're in the appendix see if we can get somewhere a little bit more straightforward okay we clicked on the wrong one here so we need to click on 5.2 and this is going to show you kind of the template for implementing that kind of function so the node.js crypto library is just implementing this standard right here and we can actually come up and see some information about it so i think there's something on iteration count it says that they recommend at least a thousand we put in well you want to have 10 million for a super secure implementation we are somewhere in the middle with 10 000 which should be fine and then it also talks a little bit about the salt up here and you can read up about what that actually is a lot of this is just math so i don't want to get into it but this is kind of where the standard comes from so we're not just using some random crypto function this is kind of what the engine internet engineering task force has designated as this is how you should do it when you are verifying and generating passwords we can now come back and do the second function which is the valid password i'm not really sure why i called it valid password probably should be validate password but anyways here is the implementation for that all we're doing it this is basically the same exact thing remember what we went through on the slide we're just creating the same exact hash that we did up here except this time we're receiving the hash and the salt or well we're just passing the salt but we're getting that salt from the user record in the database and then we're getting this password when the user types it in in the login form so given the same inputs we should expect the same output and therefore we are going to return whether the hash that comes from the database is equal to the hash that we computed using the password that the user just provided us in the salt that was in the database for that user record so we're going to either receive true or false and this is what we're going to put in our passport js verify callback so let's save this and come back to our passport js configuration and you'll see that we're already using this right here we've already set it up how we want to we just need to import it so i'll do that right now so we'll say valid password equals require lib password utils dot valid password because we've exported them here at the bottom so now our passport.js implementation is complete and it should work with our application once we implement the two post routes for login and register so let's do that right now we'll come to the routes and you'll see that we have the login and register routes they're not implemented yet so we need to do that it's pretty simple so i'm just going to paste in the implementation most of this is just creating a user record in the database but we're also going to be implementing that first part the gen password function in this register route i think i have it yep i have this already imported but let's go ahead and rename it we'll just say gen password to stay consistent and then we need to grab the gen password function off of the import so now that we have that we can implement this so here's the implementation we'll walk through it really quickly i want to point out a few things before we get started we are grabbing the password and username values from the request.body.pw in unname fields if you remember from the passport configuration just to demonstrate the options you can do we went ahead and customized what we're expecting to see from that request.body object so we need to stay consistent and we need to use those to grab those values so you can see what we're doing here is we are generating that salt hash object so it's just an object with the salt in the hash so this one right here and that's coming from the gen password function that we just imported up here from the password utils then we are going to create a new user object for the database we're going to save that user we'll go ahead and just console log it to the terminal and then we are going to redirect to the login route all right so we have implemented register and we can go ahead and try that out in the browser so let's run it run the application looks like we don't have any errors so let's jump back to the browser type in localhost 3000 slash register or actually we can just go to the home page and it gives us a link to the register we're going to enter our username and our password i'll just do one two three to keep it simple and we'll submit it looks like it properly did something let's come back to the terminal to verify that good news we see the object that we just created we put the username in there and then the hash and the salt that we got from the gen password function and then we can also check the database so let me just open the shell and we'll look it up so show databases we are using the tutorial db based on the dot env file so i will say use tutorial db and then we can say db dot users dot find and you should see the user that we just created so clearly we've got the user in the database and the last thing that we need to do in this entire flow is implement the login route so if we come back to what we're already in the file we have the login route that we've already kind of put this passport.authent method in a little bit earlier but i just want to add a few things to it and we'll actually simplify this a little bit as well the first thing i'm going to do is pass in a second argument to the authenticate method and this is just going to be an object that tells passport where to redirect based on the status of the login so if you remember the passport.authenticate method is literally just going to look in the passport configuration for this verify callback and it's going to call this function right here and this is going to return either a user if we are validating the user correctly and the user has provided the correct password or we're going to say false and in that case it's going to redirect to the login failure so really since we're adding conditions for both a success and a failure we don't need this last function right here so we've just included this normal callback that we see in most express routes but we don't need that in this implementation and we are pretty much done with the login post request so let's save this and give it a try in the browser we'll type in the same user that i did earlier one two three for the password and submit and it says that we have successfully logged in so something worked here now we can go to the protected route it says you are authenticated we can log out and reload now we're not authenticated and we can log in again so we can just go in this circle here it's kind of how i set it up so that we can see that flow but i'm going to be talking a lot more about how this is actually working and how you can use the passport middleware in your routes in the next video but let's come back one more time to the code and just kind of take a look at the routes that we just went through so we started at login login submitted the data that we put in there and the passport verify callback was called we successfully validated the user so we got to right here and then we come to the route the login post route and we had a success so we are going to come to the login success route you can see this success redirect login success so we'll come down here somewhere so we came to the login success then it said go to the protected routes we clicked that link and we came right here which you'll see a little bit of extra syntax we're going to go through this in the next video but this is how we would authenticate the user once we've run through that authentication flow in the login post route and then we can also log out so we've got a logout method on the request object and then the cycle kind of repeats we are officially done with the passport configuration we've got it working completely and this is all you're going to have to do for the passport local strategy to authenticate users into your web app now i did mention earlier that we were going to come back to something and it was in the passport configuration here at the bottom so these two methods the passport.serialize and deserialize and then also i think in app.js we have these two lines the initialize in session now we don't really know how those are working and i promise that we'll come back and explain how those are working and kind of see it for ourselves in code i would also like to go through some of these things like request that log out and request that is authenticated and understand what is going on there and also kind of understand you know you would intuitively think well we're probably just going to use the passport dot authenticate middleware on every single route that we want to authenticate but that's not the case for the passport local strategy so to start what we're going to have to understand is that passport.serialize and deserialize configurations so if we open up the passport file it's these two configurations right here that we need to understand to really grasp what passport is trying to do in order to understand this a little bit better i'm going to open up app.js and we're going to write a very basic middleware that is just going to give us it's not going to do anything but it's going to give us a little bit of debugging power so we've got these middlewares working so here's where we set up the session so we include that here then we include the passport.initialize and passport.sessionmiddlewares right here so after those have done their work these are happening on every single route request we'll put in our custom middleware so we'll say app.use and we're going to pass in a simple function we're just going to give it the standard parameters and then what we're going to do in the body of it is just console.log request dot session and then we will console.log request dot user so you'll see how this works the express session is going to create this object right here and the passport middleware should create this object here and then finally we have to call next so it doesn't crash our routes but basically every time we visit any route in this application this is going to run and we're going to see exactly how it's working so for starters let's just get this running and visit in in the browser so we'll come to google chrome we'll come back to what i've got on the screen here in a second let's just go to the base route so we're at the home page and you can see in the application here is our cookie that we've set which represents the express session id so that will we're going to just delete this really quick so that we refresh everything so now we have a clean slate and the express session middleware is going to recreate a new session for us to use when we press refresh so we pressed refresh it created a new session and in the console we should see that printed out because of the middleware that we just wrote right here so you see the session is going to show us the cookie and that's pretty much it you'll notice that the request.userobject is undefined right now and that is because we haven't yet authenticated our user using the passport.authenticate method so let's do that really quickly in the browser so we need to actually just visit the login route because we've already got this user in the database if you remember from last video so we will sign in and click submit and this is the same session id come back to the code and this time we've got a different story so this time let me expand this so we can see it so here was our first go around so this is what it printed and then this is the second time so now we have the session with the cookie but we also have this line right here and this was created by the passport middleware and when we executed the passport.authenticate method which is in the login post route so right here that's what we just did and what passport did behind the scenes was create this additional property on the express session and how we got this right here is through the passport.serialize user function so right here we ran the serialize user function we passed in the user id and we stored it under the user property so let's go ahead and check to see if this is the actual id of our user so it's 5e0f now let's go over to the shell and we're already set up to query this so we'll say db.users.find and you'll see that we have the 5e0f user in the database so the serialize user function when we did the passport.authenticate method is going to grab that user from the database get the id of the user and then insert that into the passport.user or actually it would be the request.session.passport.user property so now when we need to grab this user from the the session we're going to use the deserialize user function so we're kind of seeing it all at once but to populate the request.user right here this is the middleware that we just wrote to print all this stuff to the terminal in order to populate the request.user we are going to grab the user from the database right here and based on the user id that was provided in the session object and then we are going to attach the found user to the request.user object so that was a mouthful and we've got a few more pieces to this puzzle so we'll come to app.js and these two lines are playing into this equation as well so when we say passport.initialize that's going to kind of re-run everything that we just did and then the passport.session is going to kind of work in the same way so every time we load a route these two middlewares are going to work together and what they're going to basically do is they're first going to check to see if this user property is not null so it would look something like this we would say if request.session.passport.user not equal to null then we are going to know that there is a logged in user and we're going to grab this user id from that property then once we grab that user id from the property we're going to use the deserialize user method pass in oops pass in the user id grab it from the database and then what we're going to do is populate the request.user and set it equal to whatever user we got from the database so that's basically what is happening on every single route request now if this user object is null then that means that the user is not currently logged in and we do not grab the user from the session and this property request that user is not populated if we go in the browser and we do the log out function or we visit the logout route you're going to notice the next time that we console.log these two properties that this user object is not going to exist so let's scroll to the scroll to the bottom save this um come up here so we're at the bottom let's go to the browser and first we've got to visit the protected route and when we click this button right here it's going to log us out so we click log out and reload and come back to the terminal and now you'll see that this passport object is going to not have this user property in other words we are not logged in now you might say okay this is a lot to look at and it's a lot of kind of funky logic to go through every time we want to figure out if our user is logged in or not and luckily we have some methods built onto this request object to kind of do this logic for us these methods were defined by the passport middleware or the passport local middleware and we can see this if we visit the repository so this module the request.js module is where this is going to kind of happen or where these are defined and you'll see a couple properties attached to the request object so the first one is the login property and this is actually called by default when we use the passport.authenticate method so we don't really have to ever use this on our own if we're using the passport.authenticate method now what's useful to us is the last three properties so first we have request.logout so anytime that we want to log our user out we just call this method and you'll see that i do this when we had clicked that logout button you'll see in the route for the log out route somewhere down here so here's my logout route and you can see that i have called that method right there which is basically going to delete the request.session.passport.userproperty from the session so that's all that that's doing and then next time we call the passport.initialize and passport.sessionmiddlewares which happens on every route it's going to check that property see that it's null and pretty much declare that the user has been logged out all right so the next one we have is the request dot is authenticated and this is a really common one we're going to use a lot and basically all this is doing is what we went through manually and there's a bunch of funky code here because it's part of the framework but basically all this code is doing is saying does the request.session.passport.userpropertyx property and is in it is not null and if that is the case then we declare that the user is authenticated because the only way that that property would have been populated is after we use the passport.authenticate method which is going to run the verify callback which is going to implement our custom login logic finally we have request that is unauthenticated i don't really use this it's just the opposite of the request that is authenticated so you can use it but it's not really all that complicated so we've got these methods unfortunately these are not documented very well in the passport documentation which is kind of a shame but anyways let's come back to our code and see how we might use these properties to our advantage so right now in our routes we are manually calling these things and right here we are manually checking whether the request is authenticated and then if it is we are doing something if it's not we're doing something else so in order to streamline this a little bit it would make a little bit more sense if we included this as middleware and all we're doing is checking if the user is authenticated and if the user is authenticated we just call the next callback and it goes into the route and if the user is not authenticated we return some sort of 401 unauthorized error so to make our lives a lot easier let's go in the routes folder you can really put this anywhere i'm just going to put it in the routes folder and we'll just say off middleware.js and in the off middleware js i'll just take you through two different middlewares that we could implement you can get as creative as you want with this but here are some pretty standard ones that you might use so we'll say module.exports dot is off equal to a middleware function so there's the standard middleware parameters or arguments and then we're going to do something in here to check whether the user is authenticated and if they're not we're going to return some sort of 401 unauthorized error the second one we're going to do module dot exports dot is admin so currently we don't have an admin property on our user schema but we could easily add that and we could use this middleware to basically check whether the user is logged in and is an admin so that can help you kind of protect routes that are for admins only versus regular users we'll get to that in a second but first let's get this one done so all we're going to do is use that request dot is authenticated method that is attached from the passport middleware so we'll say if request dot is authenticated then we're going to just say next and pass it on to the next middleware in the chain if the user is not authenticated we'll just return a 401 unauthorized error so we'll just say res dot status 401 dot json and we'll just put in a message that says you are not authorized to view this resource all right so that's pretty simple so if they're authenticated if they're logged in we're going to just pass it on to the next middleware in the chain if not we're going to just stop it right there and return an unauthorized error all right so let's test this out so we have the is off middleware if we come to our route let's do this let's kind of refactor this so in our protected route we're going to return res.send you made it to the route so something to indicate to us that we successfully made it into the route and within this route we could do whatever we want we could return some sort of data and to do this we will just pass in is off as the middleware right there and of course we need to import this at the top of this file so we will say is off equals require off middleware dot is off all right so we've got this set up and now if we try to visit the protected route we should hopefully see you made it to the route so let's try that go to google chrome and we're already at our protected route so oh it looks like we are not authenticated right now because we had logged out so let's log in really quick so we are logged in and when we click go to protected route we should see that message that we just put there it said you made it to the route so our middleware is working now let's visit the logout route so that we can log ourselves out and then see if that other status is going to work so now we went to the log out route and we were redirected to the protected route i'm not exactly sure how that worked but we got the error message that we were expecting and if we were using you know a front end we could kind of process this error in a clean manner and give a friendly message to the user so we've got our middleware working and now all we have to do is pass in this short variable before any route that we want to protect so the next thing is just kind of an added bonus it's not necessary for all applications but it's something that kind of just stretches your creativity a little bit it gets you thinking outside of the box and we're not just constrained by some framework that tells us that we need to do it this way so in order to implement the is admin we are going to come to the database and add one more thing to this user schema so we're going to add an admin property which is going to be a boolean and we'll save that and then we need to actually register a new user so that they have this admin property and we'll just by default put this new user as an admin um let's see where that happens is going to be in the register route um where are we okay so right here is where we're going to do this currently we're just passing in this data but i'm just going to hard code in the admin property and we're going to say true so save that we will come back to the browser and we need to go to the register route so let's go to register let me get rid of this and i'm going to say zack 2 and we'll do the same password one two three just so i don't forget it submit we have put this user in the database let's go ahead and check that just really quickly to make sure so we'll come to the shell db.users.find now we have two users in the database let's kind of extend this and the second user zac2 has an admin property of true so zack the original zach is not an admin because we haven't added that property the second one is an admin so the first user should be able to visit an admin route while the second should not so let's test that out really quickly we need to make a route that will actually test it so let's come down to protected route just copy that and instead of protected we'll say admin route so the first thing we want to check is the is off we kind of have some freedom how we want to do this i'm going to go ahead and simplify things and just say is admin so we don't have to repeat it so we could do is off and then is admin and in the in in this middleware all we have to do is check whether that property exists but i'm going to go ahead and simplify that you'll see what i mean in a second so we'll say is admin we need to import that here at the top so i know this is you know not really good coding practice we could refactor this a little bit but we'll do it just for the sake of time so we've put the is admin middleware in there we've included it in the admin route and we'll say you made it to the admin route if they successfully make it through that middleware gate so now we come back to the auth middleware and let's just copy the same exact thing except this time we're going to say if request dot is authenticated and request.user.admin since this is a boolean property we can just say this so now we have two requirements to get through this authentication middleware and then we have the same exact um logic here maybe we'll change the message to say you are not authorized to view this resource because you are not an admin all right so we've got this set up and i think we should be able to visit the route that we just created so admin route let's just manually type that into here and since we haven't i don't think we've logged in with anyone yet so let's log in with the first user so this one should not be an admin and we'll go to the admin route and it'll say you are not authorized to view this because you're not an admin as we would expect now let's log this user out by just going to log out and then let's go to login we're going to log in that second user that does have admin privileges oh looks like we had some sort of login failure maybe i just typed it in wrong um oh it was because i put the wrong username in so it's not zac one it is zach2 and one two three all right we are successfully logged in let's go to the admin route and this time we should get a success message you made it to the admin route so we've covered a good amount here but hopefully this kind of opens up your creativity into understanding how the passport local strategy works how we can use it to creatively authenticate and allow access to different resources based on whether a user is logged in or logged out based on whether a user has admin credentials and you could even go through some more complex logic if you wanted to by creating different types of middlewares i know it seems like we've already run a marathon just trying to get the passport local strategy implemented but again authentication user authentication is not an easy subject i think we kind of treat it as an easier subject because it's like okay there's only a few moving parts here it seems like on the surface but once you get into the implementation there are so many different things that you have to understand in order to debug and have a solid grasp around user authentication i want to take a minute to say congrats there's been a lot of content so far and you have finally implemented your first official you know user authentication scheme where you actually know what's going on behind the scenes you can walk away from this tutorial right now if you want to but there is a second part to all of this which is the jwt based authentication that i think is super super important to know and it's probably one of the more popular ways to do it as i mentioned in the first you know a few minutes of this video but as we saw with passport local strategy having all of these prerequisites we also have some prerequisites for implementing a jwt authentication strategy in this section we're going to be tackling one of those prerequisites which is public key cryptography now i will make the disclaimer that to implement the passport jwt strategy or a jwt strategy in general you don't need public key cryptography in reality you could very well just use a symmetric cryptography scheme which is basically where you just make a long secret string and store that in an environment variable and then use that to you know authenticate through jwt now i chose public key cryptography over something like you know symmetric secrets because of a couple reasons number one i think it's really cool um public key or asymmetric cryptography is a really fascinating subject and it's also kind of the basis of bitcoin in a lot of those cryptocurrency systems so not only are you getting an education on user authentication but you're getting a basic education on how cryptocurrencies work as well and the second reason is this is arguably more robust of a solution than a basic secret key but in all reality if you're still watching this course then you're probably the type of person that would be interested in these extra little details so let's go ahead and dive into a basic introduction to public key cryptography this is a widespread topic public key cryptography and cryptography in general can be used for several different things whether you're talking about user authentication cryptocurrency or even just secure transport over https so i'm going to in this video be talking about what is public key cryptography and how does it work from both a conceptual and practical level so we're going to walk through the basics of you know conceptually how it works but we're also going to look at some code and see it in action before i get into what public key cryptography is we need to distinguish between two terms so that would be asymmetric and symmetric cryptography so public key cryptography what you see on the screen is a form of asymmetric cryptography because you have a public and a private key associated with it now a more basic form in what is used for tls or transport secure layer or whatever i think that's what it is otherwise the protocol that we use to transport data securely over an insecure internet channel that is going to be symmetric cryptography and is identified by a single key so a great way to think about this is maybe in a classroom setting so say you're sitting in a classroom and you want to pass a secure note to some of you know one of your friends across the room but you want to make sure that if the teacher intercepts that message they can't read it so what you would do is before class you're going to connect with your friend or friends that will be basically interchanging notes and you need to come up with a secret key so you might just come up with a real simple secret key and that key is going to be okay we're going to take every letter in the message and we're going to increment it by two so an a becomes a c and then to decrypt it you just have to take that c and bring it down two letters to be an a so now that the people that are interchanging messages know what the secret key or the cipher algorithm is they can easily read what the teacher thinks is gibberish when the notes are passed so to encrypt the data one student is going to basically you know write something down write the message that they want and then they're going to transpose it using the cipher algorithm so once again an a becomes a c a b becomes a d and so forth then they'll have someone you know walk that note across the class or pass it from desk to desk and we'll say that the teacher intercepts it the teacher cannot figure out what the note says it just looks like gibberish but the student on the other end could have decrypted that message by using that secret cipher so that is what we call symmetric cryptography and obviously we need to protect that secret now this is again used in transporting messages over the internet it's also used a lot in web application development you'll commonly see something called a secret key and that is what you'll be using to encrypt some sort of data now on the other side of things we have public key or asymmetric cryptography which is a little bit more complicated and involves a private and a public key pair so these private and public key pairs are mathematically linked as we'll see a little bit later in this video but the basic gist of it is if you have a public key you can give this to anyone as long as you keep the private key secret and then we can do two things with that public private key pair the first use case is going to be exactly what we just talked about with encrypting some sort of data so you might think of this the way that i like to think of it is a padlock and a key so basically i mean this is kind of a contrived example but basically think about maybe we're sitting in that same classroom and we have some sort of lock box and so one student is going to write a note which is just going to be in plain text and they're going to put the note in the lock box so what they'll do now is they will close the lock box and lock it with a padlock so that padlock before class was actually given to the student by another student who actually owns the key to the padlock so just to level set here the student that's writing the message has the public key of the other student who will eventually receive that message and decrypt it with the private key that corresponds to that public key so in other words student writes the message puts it in the box locks it with the other students public key then we send the box across the room we'll say the teacher intercepts it tries to open it but of course they don't have the private key that corresponds to that padlock or just the physical key that will unlock it so they can't unlock it can't see the message but if it gets to the student who does have that private key they can just unlock the padlock open the box and see the message so that is your first use case now the second use case is a little more complicated and we're not going to be able to understand it in the form of the classroom setting we're going to have to get into a little bit more complicated math but that second use case is called a digital signature or identity verification and this comes in handy when we're talking about user authentication and is pretty much the entire reason for me making this video so again if you're following along the passport.js user authentication series what you're going to want to really focus on in this video is that second use case or identity verification as you'll see to use these two use cases all we're going to do is change which key we are encrypting and decrypting with so to encrypt some sort of data but not protect an identity we're going to encrypt with the public key and decrypt with the private key as with the padlock and key in the classroom now the second use case we're just going to flip that we're going to encrypt with the private key and decrypt decrypt with the public key now in order to understand this we have to understand what a trapdoor function is and this comes in several different forms but in the case of public key cryptography or asymmetric cryptography we're talking about elliptic curve multiplication we'll get to that in one second but first let's just generally understand what a trapdoor function is so basically what a trapdoor function is is a one-way function that takes some pretty big piece of data and compresses it into a deterministic small piece of data outcome so in other words we can have an infinitely large piece of data we could have let's say something as simple as what you see on the screen right now or we could have something as big as maybe an entire book and what we can do is we can take that infinitely large or small data and put it through what we call a trap door function in this case we're using a sha 256 hash function and that will always create a deterministic outcome so it's going to be the same length i think it's i don't remember off the top of my head exactly how many bytes this is but it's a hexadecimal representation of the data on the left so if we were to come to an online sha 256 hash calculator i've pasted in that exact value in json string form and we get out this hash value and so anytime we put this particular data into this sha-256 hash function we're going to get the same exact output every single time so it is deterministic you can try it for yourself now we also have to know about this that we cannot go backwards so from this data on the right there's no possible way that we can derive what the original data was in the first place even though we know that we're using the sha-256 hash function we know that that's only one way you can't go the other way the last important thing to recognize about this is we have an infinite number space essentially now it's obviously not actually infinite but there are so many different combinations that the sha-256 hash function can produce that the chances of us having two different pieces of data that come to the same hash value is essentially impossible now there's plenty of stack overflow questions on this and you can read up on them on your own time but basically the probability of this guarantees that we're always going to get a unique hash value what we're interested in when it comes to public key cryptography or asymmetric cryptography is a one-way function or trapdoor function called elliptic curve multiplication now it's not actually multiplication it's a cryptographic function and basically all we need to know about this is that it mathematically links the private and public key so in other words using the using the private key we can derive the public key but having the public key we can never get back to that private key so in other words we can share the public key with anyone in the world and they'll never be able to figure out what private key corresponds to that public key this again is useful for those two use cases of either protecting some sort of data or verifying an identity we'll see a little bit more how this works when we actually get into the code but first let's kind of take a quick glance at how elliptic curve multiplication works so on the right you'll see the elliptic curve graph which is useful to us because given any point on kind of the on this graph we can take the tangent of that point and get to another point on the graph so say we're right here on the graph well this curve extends infinitely so we can just take the tangent all the way up to that curve so let's go to the next slide and first start out with what we call the generator point now the generator point is an arbitrary random value or coordinate that we will always start with now this point in many cases is going to be a fixed point that we use for a large private key i guess you could say number space so we always start with the same generator point but then the variable in the quick equation is the private key and we take that private key and we multiply the generator point by the value of the private key so again the private key is some infinitely well not infinitely but it's some small or large value and so we can just like we can take g times two and g times three we can also to do g times you know 10 trillion or whatever the total value of that private key is now you might ask how are we going to multiply g that doesn't make any sense this is a graph and how are we going to actually do multiplication well the way that that works in elliptic curve multiplication is by drawing tangents as we talked about so you start with the generator point and say that your private keys value is two now obviously it's never going to be two it's going to be a much much larger number and we're going to do this process many more times but essentially what's happening is we start with g we draw the tangent to that point on the curve which the tangent intersects this other point on the curve then from that other point we say okay what is the opposite side of the curve so we draw this completely vertical dotted line to get to this last point on the curve and that is essentially the multiplication value of our operation so g times 2 is going to equal this coordinate down here at the bottom so you can see how this is kind of it's not exactly the multiplication that we're used to but essentially what is happening is we start with this arbitrary generator point we multiply or we go through this process however many times the public or the private key value is and eventually we will reach a certain point on the elliptic curve and that is going to represent our public key now we cannot get back to the private key based on the public key coordinate but what we can do is we can derive that the private key that may be signed a message corresponds to the public key so if we so in other words what you need to understand is that using the complex math the elliptic curve cryptography does we can actually verify that a public key corresponds to a given private key mathematically without revealing the private key to the person trying to verify it so in other words we can decrypt a message using a public key you'll see how this applies a little bit later in the video just to recap before we get into the actual code if we want to do data encryption we're going to encrypt with the public key and decrypt with the private key if we want to do identity verification or a digital signature we are going to take the message that we want to sign and we are going to essentially sign it with our private key and then some random party you know some receiver of the message is going to have somewhere the public key that corresponds to the private key and using that public key as we just talked about we can use that elliptic curve algorithm to verify that yes indeed the person who signed it has the private key that corresponds to that public key okay so let's take a look at the actual code that will create this private and public key pair now there's of course command line utilities that you can use to do this but i wanted to kind of write it out so that we can explain it and understand it a little bit better let's go to vs code real quick and create a new file we're just going to call this create keypair.js we'll open up this file and i'm going to paste in some code that i already wrote so let's walk through this code really quick we're using the built-in nodejs crypto library and then the built-in node.js file system so that we can output the keys in this directory and you'll see what's happening is we have a single function that will generate a key pair all it's doing is using the crypto library to generate the private and public key using that elliptic curve multiplication under the hood and then we're going to write that private and public key to separate dot pem files in the current directory so you'll see that here is where the magic is actually happening and then down here is where we're taking those values and writing them to the files so you can see that we're using the rsa algorithm to generate the keys that's a pretty standard algorithm to use and then these you can just go ahead and look at them on your own if you want to pause the video to see what they represent but basically this is all the math that we just talked about and when we run this script by saying node create key pair it's going to finish and then you'll see on the left we have both a private key and a public key in other words this private key is something that we want to keep to ourself not share with anyone and the public key can be shared with absolutely anyone with full confidence that they will never be able to figure out what this private key is all right now that we have our private and public key let's go ahead and use that in both of those two use cases that we talked about earlier so to do this just remember we have the private key and public key saved in this current working directory so i'm going to close them i'm going to close the create key pair and then i'm going to create a new file called encrypt.js and in this new file we're going to write an encryption formula where we take some sort of data and we encrypt the data and we protect that data so i'll paste in the code you're going to see we require the crypto library again and then i've got a single function that's going to take a public key and a message as an argument so again if we want to protect data but not an identity we encrypt with the public key and decrypt with the private key so what this file is going to do is it's going to take the message that we give it it's going to create a node buffer with utf-8 formatting from that message and then it's going to pass that buffer into the built-in public key encrypt function that the node crypto library provides us with and then what we're going to do is we're going to export this function so that we can import it into another module so now that we have this we can save it and then create one more file called main.js where we're going to do a lot of the work let's go ahead and open up main.js and copy in some code that i already wrote a little bit earlier so again we're using the file system and then we're also importing this file right here that we just wrote so by importing this we have access to the encrypt with public key function and so what we're going to do in the main file is we're going to first get access to the public key that we created and stored in that pem file in the current working directory so we just use the file system to do that and then what we're going to do is create an encrypted message and store it in the encrypted message variable so you'll see that we're going to use the function that we defined in this other module we're going to pass in the public key that we got from the file system that we created earlier and here is our super secret message that we don't want anyone to be able to decrypt over a public channel so once we do that we can basically console log the encrypted message as a string and you'll see when i save and run this file that in the terminal you'll see some gibberish that we cannot decrypt so node main.js and of course we see a bunch of gibberish this means absolutely nothing to us and there's no chance that we figure out what this super secret message was based on this data so in other words this right here is what you're going to transport over any sort of insecure transport layer so to decrypt this we can do that with our private key so let's take a moment to see how that works we'll clear the terminal and create another file called decrypt dot js and when we open that up we can paste in a similar function to the encrypt file so we're going to require the node crypto library define a single function where we decrypt with the private key and then all this will take is our encrypted message and the private key and then it will use the built-in node crypto library private decrypt function so we're going to export this function so that we can import it in another module save it and then we're going to use the main module to actually decrypt this okay so you're going to have to use your imagination a little bit because we're both encrypting and decrypting in the same file but hopefully this will make a little bit of sense so at the top part of the file we have encrypted our super secret message right here at the bottom part we are going to import our private key and then we're going to use the decrypt function and we're passing that encrypted message into the decrypt function and finally we'll take that decrypted message and convert it to a string and print it to the console so what we should expect with this file now is that in the console we're going to get that gibberish message that is encrypted and then finally we will have the decrypted message which should say super secret message so let's run that real quick we'll say oop come down to the terminal we'll say node main.js and we have a problem so let's see what the problem is decrypt is not defined because i did not import it so let me import that real quick now that we've imported it we can use the function let's try one more time so we got the gibberish up top and then we finally got the decrypted message at the bottom so that is just a basic way that you can understand how we use private and public key pairs to protect data over an insecure transport layer in order to see how digital signatures work we're going to have to add a few things to our encrypt and decrypt modules because remember we are going to encrypt and decrypt with different keys based on which use case we want to use so let me do in the encrypt encrypt function or module i'm going to add another function called encrypt with private key so we can encrypt with the public key in case of data protection or we can encrypt with private key in case of a digital signature so let's go ahead and export that from this module real quick so encrypt with private key so now we have a module called encrypt which we can do both encryption with the private or the public key likewise we need to do this in the decrypt module so let me just highlight this whole part paste it in we've got an extra import here and we've got our function decrypt with public key so now that we have those components we can see how a digital signature actually works but mind you a digital signature is a little bit different than protecting data we're going to have to go through just a little bit extra work to do this because this is a little bit more complicated i'm actually going to make separate files for the steps of the process so with the digital signature we have some sort of data that we want to put our signature on so just think of it like a legal document you have the document itself with the data and you want to sign it and you want to make sure that the receiver of that data is assured that both the data that was on the document has not been tampered with we don't want someone intercepting it and changing some of the legal proceedings on that paper and we also want to make sure that the person we think signed it actually did sign it so that's step one we need to sign the message step two is actually verifying it as i just described so for step one let me go ahead and close all of these files you know what's you know what is in them so we will create a sign message dot js file and in this file let's go ahead and import some different modules so let me walk you through what's actually happening here starting from the top we have the node crypto library pretty familiar we also have the file system and then we have the encrypts and decrypt modules that we created ourselves now the last thing is this hash function and this is a sha 256 hash we talked about this a little bit earlier and it is a trapdoor function that takes a pretty much infinitely large or small piece of data and you put that data through the hash function and the output of that hash function is going to be every single time you do it it's going to be the same exact value and that value is going to be small enough that we can kind of transport to different places it's always going to be 64 characters long which each character is four bits so you have 260 or 256 bit value that is always going to come out of that function no matter how big or small the data you put into it finally at the bottom you'll see that i have a piece of data this is going to be the data that we're going to sign now you'll see that i've got my first and last name and then in the social security number field we're never going to put that because remember this second use case of signing some sort of data does not protect the data itself if someone intercepted this data on an insecure channel they would be able to read everything that is contained in it so we never want to put any sort of confidential information in data that we are digitally signing all right so the first thing that we need to do is we need to take this data right here since it's pretty large and we need to compress it down into that sha-256 hash so to do that deleted it to do that i'm going to paste in some code that i wrote earlier and what this code is going to do is first store the json string value of this data right here and it's going to store that in a variable and what we're going to do is we're going to use that node crypto library hash function and we're going to hash the data that i just put in string form then we're going to convert that into hexadecimal format and this is important because the format that we're passing values between function in is actually really important when we're using the crypto library we are now ready to actually sign this data so let's paste in some more code first we're going to get access to the private key that we created earlier in second we are going to store the signed message in a variable we're going to use the encrypt with private key function that we created using the node built in crypto library we're going to pass in the the sender private key so in this case i am the sender of this data and i own a private key that i'm going to sign this message with so i will sign the data with my private key and this data is going to be in the form of the hash data so we're not just going to sign this big data object we're going to sign the hashed version of that data now the last thing that we have to do is kind of that extra step that i was talking about so if you just sent this signed message to someone they're not going to be able to do anything with it not only do we have to verify that nobody has tampered with our legal documents so to speak we also need to verify that the person that says they signed it actually did sign it to do that we need to provide the receiver of this data with a few additional pieces of information so those pieces of information is number one which hash function we used to hash the data number two we have to actually give them the original data so that they can take the hash function take the hash of it and then they can eventually take the signature that we provide them with and match it up with that hash data to make sure that the that i actually signed the data in the first place so let's go ahead and see what that looks like we'll go ahead and create a final piece of data so we'll say package of data to send to be very explicit and we'll paste in this data object so we've got an algorithm so this tells the receiver of data i want you to use the sha 256 algorithm and what i want you to put in that algorithm is the original data that we created so you'll see that the original data is my data which is the original object of data that we will use and then of course we have the signed and encrypted data which we assign to the signed message right here so with this information a receiver of this data can verify using my public key that not only was the data not tampered with but i also signed it last let's go ahead and export this package of data so module dot exports dot data or let's just call it the same thing that we called it here package of data to send equals package of data to send so we can access this from another file to do this we're going to create another file called verify identity.js we'll open up that file and we'll put our imports in there so we need the crypto library we need that decrypt module that we had created on our own and then we need to import the data that we just exported from that other module so this is everything that we need to verify this message now we also need to bring in the public key of the sender so this will be made publicly available and we'll say that you know i sent this data in the first place but my friend jim whatever is going to be verifying it so jim will need my public key to do this which again public key is public and anyone can see it you can feel confident that they're never going to be able to figure out what the private key was and one thing you'll notice that i required this in but i need to grab the variable that we exported so require this module and the variable so our received data is equal to this object right here in the sign message file next we need to actually take our own hash of the data that we were provided so to do that we know that we're using the sha-256 hash and so we can use that hash function to hash the original data i'll paste this in here and you'll see that our hash function is going to be the built-in node hash function and it's going to be the algorithm that was in that data package so i know this is a little confusing but this line right here in the verify identity file is the same as this import right up here so where we said create hash sha 256 we're also creating a hash and we're just using that algorithm that we've received in the data package like i said we also need the public key of the sender so we'll go ahead and get that in the public key variable the next step to doing this is we have to take that data that was signed and decrypt it so let's think about what this is actually doing i'm going to paste in the code and we're going to use our decrypt module we're going to pass in the public key right here this is the public key of the sender and then we're going to take the the data that we received and we're going to pass in the signed and encrypted data so if we come over back to the sign message let's figure out what this was so our signed and encrypted data was our signed message which basically if we decrypt that message what it's going to give us is the hash value that we derived from this original data so what we're going to get in this variable right here the decrypted message is simply a hash value so in order to verify that we can then take our own hash of the data that was provided in this object right here so this is the original data and if we take a hash of that and compare it to the decrypted message here they should match and if they do match we can know that not only was the data not tampered with but it was also signed by the person who said that they signed it one extra step we've got to do is we've got to turn that decrypted message into a string value to pass it into our function that's just a formatting thing finally we say we want to look at the hash of the original so we're going to actually take the hash of the data that was passed to us in that data package and then we're going to turn that into a hex value to verify it we'll just do a basic if then statement so we'll say if the hash of original hex so basically our own so this is the receiver of data jim is doing this he's taking a hash using the designated hash formula and just turning it into a hexadecimal value so that we are comparing apples to apples and then we're taking the decrypted message hex which is basically what came with that is what we decrypted in comparing them so if it is the same then we're going to say success the data has not been tampered with and the sender is valid so let's see if this works let's go down to our console and run node verify identity and you'll see that it says success data hasn't been tampered with we have the right sender so hopefully that makes sense that is the second use case of public key or asymmetric cryptography and is called a digital signature it's a very common way to verify data and identities and you'll see if you are following the passport.js series that this video is kind of associated with you'll see exactly how that works when we actually are authenticating users now just as a consolation for this video what we just did over the last few minutes when we were signing and verifying a message is the same exact process that is used with json web tokens so you might say wait a second there might be a better way to transport this package of data over the internet and you are right there is indeed a better way to do this if we were to send this package of data it's going to actually be a pretty large piece of data and it's going to slow all of our web searches down especially if we're using it for some sort of authentication so naturally the easier way to do this is to represent this piece of data in a much smaller form just like we took the original data and we took a hash of it to make it smaller and more transportable we can also do that with the data package that is sent to the receiver of data and is used to verify the original data let's jump into the browser real quick and what i have pulled up is jwt dot io which has a really simple jwt visualizer per se now don't focus on what is going on here because i have a separate video on that but just recognize the structure of what's going on so on the left this is our entire jwt token and you can see that it is pretty short and it would be very easy to transport over the internet in a quick and efficient manner but if we decode this jwt it has the same critical information that we saw when we were signing and verifying an identity in our code earlier so first we have the algorithm which is represented by this reg string and so this will tell us exactly what sha or sha 256 hash algorithm that we have to use to decrypt the data then we also have a payload which is represented by this purple string and you can see i guess i deleted something here but you can see that it has all of the information that we would need to include in that payload of data so this you could consider that legal document that we are signing and then finally at the bottom you have the actual signature and the signature is going to include um you'll see the public and private key here but this is actually just going to be the signature that we wrote in the code earlier and we can verify it with a public key all right now that you have a basic understanding of public key cryptography we can move on to understanding what is a json web token now i could of course go through a basic example and just show you the pieces and all that stuff but i want to take it even further as i promised this is you know hopefully one of the most detailed user authentication courses that you've ever taken and in that light i want to actually derive and sign our own implementation of a json web token using some of the internal node.js libraries the questions that i'm going to answer in this video is first what is a json web token we will then go into answering the question of how do we derive a json web token like what are the pieces of it and how would we actually create one using code and then finally i'll give you a little bit of context as to how it applies to user authentication among other use cases we'll start the video off by looking at the jwt or json web token spec on the internet engineering task force it is going let me switch to google chrome real quick you'll see that they have a write up on jwt's and the specification for using them we'll come back to this in a minute to look at a few things but um this is a very well established type of token per se i guess you could call it a token that we use to transport some sort of data on the web now something a little bit more friendly that we can look at is a website called jwt dot io and right here i am looking at the example jwt and we're going to be able to visualize what is going on a lot easier once we kind of understand what the jwt is we'll actually go into writing some code to kind of replicate this example right here so to understand jwt it's pretty simple there are three parts you have the header the payload and the signature now the header and the payload pretty easy to understand the signature not so much because there's actually multiple types of signatures that you can do and therefore it adds a little bit of complexity on top of that a signature is a digital signature and it has to do with public key cryptography or just symmetric cryptography depending on which algorithm you're using so it requires a little bit of background knowledge which is why i recommended watching that video that i had created on public key cryptography before this one now you'll see in the algorithm field up top we can kind of scroll through all the different choices that we have for writing a digital signature on a jwt but in our case since i had you watch the public key cryptography video we're going to do the rs 256 algorithm which is basically as you'll learn more when we get into the code is telling us two things so number one we're going to use rsa private and public keys that standard and then number two we're going to use the sha 256 hashing function to actually take a hash of the header and payload data i know that's a mouthful we haven't learned anything yet so just hold on to that knowledge in the back of your head we'll come back to it and understand it in a lot greater detail in a few minutes let's start out by getting a basic understanding of what a json web token is so i mentioned that it was made of three parts you have the header the payload and the signature and these are highlighted on the page here in the different colors and they are separated by a single period so the first part in red is the header then you have the pink part which is the payload and finally this turquoise part is the actual digital signature now what you're looking at right here is base64 url encoding and i'm not going to get super into it but just a few fun facts about base64 url encoding it's a encoding spec that basically aims to standardize character sets and it's derived from the base64 encoding which was originally created well before you know my time of learning to code but from what i understand the idea there was previously before the utf-8 standard where we had you know standardized character sets there was debates over whether you know there should be four bits or five bits or seven bits or eight bits within a single byte of data and before that was standardized as eight bits per byte there was varying use cases and different you know protocols and applications would use different number of bits in a byte and so therefore you might have an application that actually cuts off the last two bits of data so what base64 was aiming to do was basically add this thing called padding into the data and so it makes it so that there's no chance that any of the data is going to get lost in transport and then the base 64 url encoding is just one extra step because there were some characters within the base64 encoding that are not exactly url friendly or file name friendly so converting base64 to base64 url just makes it safe to transport over the internet and we also know that this format in general is not going to lose any data which is obviously very important when we're talking about user authentication which is a very common use case for jwts i know that was a bit of a long-winded explanation of an encoding um not so interesting but as we actually derive this jwt with code you're going to see that we're kind of constantly having to shift between the different encodings and it's going to become a little bit more important later all right now that you know what you're looking at here on the left let's talk a little more conceptually what we're seeing here on the right side so on the right side all we've done is we've taken these base64 url encoded characters and we've decoded them into json objects and in the header you'll see that we just have a couple things we have an algorithm and a type and this is pretty self-explanatory but when you're transporting json web tokens over the web it's not always the case that the receiver of the json web token is going to know you know anything about the json web token to start with so in the header the sender of the json web token or the issuer is going to identify which algorithm they use to create the digital signature and then of course we say that the type of token is a jwt because there's actually other types of token tokens that we can use here aside from just json web tokens so we have again chosen the rs 256 algorithm which says we're using public key cryptography for the digital signature along with the sha-256 hashing function and what we're going to do is well actually before i get into this let's cover what the payload is then we'll get into that signature so the payload is basically going to be metadata about some entity and in most cases it's going to be about a user because jwts are commonly used for user authentication so in this payload you're not going to see any sort of credentials if you see credentials in a jwt payload then you know that the developer has done something wrong because you should never ever put credentials or sensitive information in the payload it's publicly available anyone could decode this jwt just using a simple base64 url decoding algorithm so what this data gives us is just general information about the user so you'll see the sub or subject is going to tell us who the user is in many cases you'll see some sort of database id put in here so that when an application decodes the jwt they see okay here's the sub it is this id let me look up this id in my user table and retreat retrieve the full user object so that's what the sub is um name obviously just the name admin just another metadata property and then iat is issued at so it gives you the time stamp of when the jwt was issued now we also have additional um what they call claims that's kind of the proper term for these pieces of data we have additional um claims that we can define and if you go over to the specification for jwts you have all this information but down here at the bottom or somewhere in the middle we have the registered claim names so these are registered it says the following claim names are registered in the iana json web token claims registry established by section 10.1 so in other words these are kind of the official claims that you'll be using and if you wanted to issue jwbts that would be interpreted by various applications you would want to use these standard claims so that everyone knows exactly what they mean so let's just go through the most common ones and then there's a few others at the bottom you can look through on your own so first is the issuer claim this is going to identify the issuer of the jwt now in our case we probably don't need this because we are both issuing and verifying a jwt within the same application but in many cases for more complex architectures you'll see a certificate authority who is actually being it's the certificate authority acts as the third party authority that is trusted to issue jwt tokens and that is literally all they do so we have we basically can establish a centralized authority that everyone trusts and that centralized authority will sign the jwts with their private key and because they sign it with their private key they'll say okay here's our public key and anyone in the world can say okay i trust that institution and i'm going to verify this jwt with their public key if it matches i know that this jwt was issued by a trusted authority so that's kind of where you'll see the issuer claim the subject claim we already covered the audience claim is going to generally be the resource that will accept this jwt so in other words um if the jwt is only intended to be used with a specific application um it would probably list some sort of url or base url that will identify which server the jwt is valid for so in other words if google issued a jwt token they might put in the audience claim www.google.com and if the jwt is attempted if if you attempt to use the jwt in a different context other than google.com it's going to be rejected then finally we have the expiration claim which basically tells you when or what point in time this jwt token is no longer valid there are additional claims that you can put in here we saw the iat issued at claim but you can also and this is important you can also make up your own claims this by no means has to be standardized you can put whatever metadata that you want in the payload and last but not least we have the signature at the bottom we've already kind of touched on it i talked a lot about how this actually works from a cryptography perspective in that video that i asked you to watch before this one again link is in the description for that but anyways i think it would be helpful to go through kind of a conversation between the server and the client to understand how this jwt is working in real life so i've put together a basic little representation of this and what we have here is what i kind of perceive as the conversation that the server and the client would have if they could talk to each other in human terms of course so the server just think of this as any application we're kind of removing the idea of certificate authorities from this basic equation we're just going to assume that the server will just say it's an expressjs application is both issuing and verifying the jwt tokens so we don't have that third party certificate authority in this equation so what's going to happen is our client or just basically our user someone sitting behind a computer who is visiting our application on the web is going to go to the login page and say hey server i want to log in to your application here's my username and my password then the server gets that information in the form of a post request and it's going to say okay let me check on that i want to go through my verification algorithm and look you up in my database to make sure that you exist and you entered valid credentials we'll assume that the user did so the server says okay your credentials look great i'm going to sign a jwt token or jwt with my private key that only i know about so the server is the only entity that has any knowledge of that private key they're going to sign it and send back the jwt in the response body so then the client or the user basically this this doesn't actually have any user interaction it's invisible to the actual person behind the computer but the browser or the frontend application is going to receive the the response and say hey thanks for the jwt i'll keep this stored in my browser's local storage until maybe it expires so then the client is going to once they're logged in they're going to want to do something so maybe this client wants to go edit their profile so they'll type in the url of the profile just say some site.com this is just an arbitrary value and then they're going to need to attach that jwt token or i keep saying jwt token but it's json web token to the http header that's called the authorization header and so in the authorization header is where that's going to be stored the server is going to receive that jwt in the request body and then we're going to say okay i just talked to you we're familiar but i still need to verify that jwt because i don't know if in the time that you chose to visit the profile did someone tamper with it so we're going to take the jwt and now the server says okay i signed it with my private key but now i'm going to take my public key that everyone knows about but i don't care because it doesn't actually matter i'm going to take that public key and verify the signature on that jwt and the server says okay that signature is indeed valid i know that you know you are actually you and the claims made on the body of this jwt are valid let me go ahead and look you up in the database load your user profile and give you the information required to actually edit that user profile so that is the basics of how a jwt works i'm going to in a few minutes go through the code for deriving a jwt but i will also mention again this video was intended to be kind of part of my node.js passport.js video series which the playlist is listed in the description below if you wanted to know more about what we just talked about how this actually works in practice written in code say for an angular application go ahead and follow that series through the end use the passport jwt authentication strategy and you'll see exactly how this works in practice but for now we're going to jump into the code editor and actually see this process written out how we issue a jwt and then how we verify that jwt just using the built-in nodejs crypto library to start off with we're going to go through this part where we issue a jwt to keep it as simple as possible i'm going to take the example off of jwt.io so if you visit this you should see the same thing and i'm going to actually be showing you how we get to this jwt how we actually issue this one and then how we verify it using the public and private key so you should be able to verify how this works by just coming to this site and you can actually follow along with the node.js crypto library so i'm going to go ahead and just copy this entire token again this is in base64 url format or encoding so i'm going to copy that and then we're going to come into the code editor and paste it in here so i first need to create a file so let's just say issue jwt.js and you can see that on the left here i've already pasted in the private and public key those came from that jwt.io website alright so i've copied in the key right here let me just put this as a string and store it in some sort of variable so we'll say const jwt equals that so this is the exact jwt that we saw from that example website now in order to properly do this we need one npm library and it's called base64 url so i've already installed it but you'll come down here to your terminal and install base64 url to follow along with this so i'm going to go ahead and require that in real quick so we'll say base 64 url and now we can take this jwt right here and convert it into something that we can actually work with we now need to split up this jwt into its parts which if you remember is designated or delimited by this period so we can do that using some simple javascript so we'll say jwt parts equals jwt dot split and we'll specify that period so now if we were to console.log the jwt parts we should have an array of those three parts so let me go ahead and try that real quick and you can see that we have an array and the array contains the three different pieces of that jwt token again these are still in base64 url encoding let's go ahead and split these into variables so i've just written this code already we basically say header in base64 url url format is going to be the first one so in our array right here we're just grabbing that piece and then so on and so forth with the remaining two now what we have to do is we have to actually take this base64 url format and convert it to something else now that we have this in pieces we can decode this with the base64 url decoder the npm module we included up here and we can see the actual json objects that these represent so let me put those in variables real quick so we have the decoded header payload and signature and we're just using that base64 library and using the decode method and we're passing in the base64 url pieces and then finally we can console.log those to the terminal and you can see what they look like decoded so let's go ahead and console.log those we're just taking these three variables here and logging them save the file let's give us some space in the terminal here and let's run this again so you're going to see the first part is the same thing that we saw on google or on the in the browser at jwt.io and the second part also so these match perfectly as we would expect and then we have a bunch of gibberish at the bottom and the reason being is because we haven't actually um decrypted the signature yet so once we decrypt the signature then it will be in a format that we can understand a little bit better now that you've seen this decoded i'm going to actually comment all of this out for a second because we don't need this we're going to actually derive this jwt from scratch so commenting that out for a second we'll just space it down to the bottom and what we're going to do is actually create this from scratch by first creating the javascript objects that we want to put in the header and the payload so you can see that these are the exact same header and payload objects that we printed in json format below now obviously these are in javascript format so we will need to convert them into json format by saying using the json.stringify method so let's do that right now i pasted in the json.stringify method and stored these two objects as json strings in these two variables the next thing that we have to do because right now these are just in json format we need to actually convert that json format into the base64 url so to do that we'll use this base64 url library and we'll just put it through the basic function and convert it so here we go copy this in i'm just copying code that i wrote before to speed things up but anyways we have new variables hopefully these are labeled appropriately for you but we have a base64 url header and payload all we've done and we actually need to change this a little bit so we're going to just use our import here base64 url and the basic function that comes with that library is just a function to convert any sort of object into the base64 url format so these two variables store the correct format for our header and our payload now we have to actually sign and issue the jwt but first let's go ahead and check this we're just going to console log these two values to make sure that we have actually converted these original javascript objects correctly so let's go ahead and clear the terminal give us some space and run this again and you'll see these two values which we can actually check from the commented out code so here's our original jwt that we just took from the website and posted right in there and you'll see that this first value matches the first value of there and then the second one if you wanted to go out there and confirm that it also matches so we've got what we need again the last thing we have to do is actually take some sort of hash of these two pieces of data and then sign that hash and put that in the signature in order to sign this we need to import a few more libraries so at the top i've imported the built-in node.js crypto library and then from the crypto library we can also implement the algorithm that we're using for this jwt so this is going to allow us to sign the jwt using this specific algorithm and then we need the file system from the node.js framework so that we can access the private and public key that we have saved in this current directory now that we have our imports let's come down here get rid of these console logs and we're going to create the signature so the first step is to use this signature function and we want to write some sort of data into it so right here we're just passing in the header and the payload separated by this period and this is going to be the data that is actually hashed using the sha 256 hashing function this is all kind of done within this node crypto library but we're going to hash this data and then we're going to sign the hash so we've loaded the data in here the last thing that we have to do is load our private key which we're going to be signing it with and then use the signature function sign method to actually sign the jwt here is the code to do that copy it in first we need to load our private key that's literally just loading this private key pen file and i actually need to change the name for this to work correctly so private key dot pem and it's important to put this in utf-8 encoding and then we are going to convert this is kind of an important part we are going to sign this data which is going to give us a base64 encoded signature so then to actually derive the jwt we're going to have to convert base64 to base64 url we can do that with this imported library right up here so i'll show you the code for that here's the code that we use to do that so we just basically take the signature that we got from the node crypto library and we convert it from base 64 to base64 url so now the signature should be in the same exact format that we were expecting earlier let's go ahead and verify that real quick so signature base64 url we'll print that out really quickly and you're going to see this value right here let's go ahead and just verify it real quick so here again is our jwt we need to come all the way out to the last piece of it and here we go there's the last piece and you can see that the first couple letters are matching up and if you were to go through all of it it's going to match to the character so right there we from scratch created a jwt token using the node.js crypto library now there is an easier way to do this and i will show you that in a few minutes but first we need to verify this jwt that we just issued since we already have a lot of the basics set up we're just going to uncomment some of this code to verify the signature so let me just make a comment for this first part probably should have just named this file jwt because we're doing both the issuance and the verification in the same file so here is the issuance part right here and then end of issuance and then here is the verification and we will go ahead and implement this now so when we verify at jwt we are basically receiving the jwt in the base64 url format in this case we just are going to use this one right here the one that we just created because we know that um it's exactly the same as that example online so to get the jwt parts we're going to uncomment that we will uncomment this part we don't need any of these things right here and i think we're set so now we can actually verify this jwt to do this we'll actually have to just create one more line in the imports and this is going to be the verify function from using the same exact algorithm so we've got the issue or the create jwt function and then the create verify or the verification function as the verifier of this jwt we have received the entire jwt right here we've split it into parts and now we have to actually do something with those parts so the first thing we'll do is we'll take the header and the payload and just like the signer of the or the issuer of the jwt did we're going to take the header and the payload and append them together separated or delimited by the period and since the the node.js crypto library only accepts base64 encoding we need to take the base64 url signature and convert it using the base64 url npm module to base64. so now that we have that we can finally i guess decrypt the signature so we're going to take our public key that corresponds to the issuer issuer's private key and we're going to decrypt the signature so the first thing we need to do is actually get the private or the public key in here so i'm going to just copy this line and use that we'll say public key and we just need public key dot pem so now that we've imported our public key that we're verifying with we are finally ready to verify this jwt so let's copy this in the signature is valid variable is basically going to run the node.js crypto library verify function that we imported right here so verify function dot verify we're going to pass in the public key that we imported from the file system we're going to pass in the jwt signature base64 format and then the most important part this will really trip you up it took me honestly hours to actually get this to work because i had not included the base64 format in the verify function so that's really important and once you've done that we should console.log the signature is valid and i think it returns a boolean whether it's valid or not so let's go ahead and try that really quickly node issue well it's not really issue jwt but bear with me we get first the signature that we were console logging right up here and then the signature is valid variable returns true so we have successfully verified this jwt and essentially we've gone through the whole process so we created the jwt from scratch and then we verified it from scratch now if you wanted you could use all the code that we just used in this example for your web applications to sign and verify jwt tokens but like i said earlier there is an easier way to do this and that easier way is using the json web token npm library and what this library is is basically an abstraction of the node.js crypto library and it gives you a little bit you know more options because in this example we were just using the rsa256 algorithm and we didn't even get into okay what if we use a different jwt algorithm so the json web token library is going to give you a lot of flexibility and it also kind of abstracts away all of the things all of these you know when we have to convert from base64 url to base64 you don't have to worry about doing that in this library so this would be the library that i would recommend using in any sort of web application where you're issuing and verifying jwts and in the next few minutes i will show you exactly how to use it to save us a little bit of time i've just copied in my implementation of the json web token library um if we wanted to accompl accomplish the same exact things that we did with the node crypto library now obviously since this is abstracted a little bit you're not going to get to see the little bits and pieces that are happening and you don't get to truly understand what is happening with the jwt but it does make your life a lot easier when you're actually coding so let me explain to you what's going on here the first thing you'll notice is i imported the json web token library i already installed it with npm install json web token so that is what that import represents we use the file system the node.js file system to grab the public key and the private key that we were using earlier so again this is the public key and private key from that example on jwt.io and then you'll notice this payload object is very similar we've seen it before because it's the exact same payload object but you might notice that you don't see the header and the reason being is that is one of the things that this library abstracts away all we have to do is provide the algorithm and the library creates the header on its own so you'll see in this next line we have a variable called the signed jwt which is a product of the json web token library sign method where all we have to do is pass in the payload object in javascript form so we don't have to do any of that json.stringify stuff and then convert it to base64 url none of that we can just pass in a javascript object then of course we pass in the private key that we want to actually sign it with as we know that's how jwts work and then finally in the options object we just have to give it the algorithm that we want to use and based on this algorithm the json web token library is going to figure out what the header needs to be so it will then combined that header and the payload just as we did with the node crypto library it's going to sign it with i actually think they use the node crypto library underneath the surface so they pretty much do exactly what we did earlier to sign this and then to verify it again just one simple line of code or a couple simple lines of code we just used the json web token verify method we passed it we pass in the signed jwt or this basically it's going to be received in the authorization http header for a web application so we take that jwt pass it into the verify function we use the public key that corresponds to the signer's private key in this case since we're doing the signing or the issuance and the verification it's just these two this key pair and then again we have to pass in the algorithms that it will accept in this case rs256 and then we have a callback function in the callback function if there's an error we know that the verification has gone wrong and either we have the wrong public key to verify this jwt with or the jwt was tampered with and we don't want to use it so let's go ahead and just verify that this works really quick so you can see it in action i will console.log the signed jwt value so let's just do that first really quickly and you'll see this value right here which if you were to match with the value online it's going to be the same exact thing so um you can do that on your own time but just trust me that is the same exact jwt and then here we can go into the callback function and let's say console dot log air and we should expect that we don't see any error whatsoever because we verified this successfully so we get null as the air as expected and then we can also console.log the payload which is the second argument that it returns and you should get the same payload that we had defined right up here except this was when we issued it and then this is when we signed it so you can see how this might work in an actual application you might have a post route that is going to verify credentials and then it will sign and return a jwt in the response and then you might have another couple routes that are like authenticated routes and you might have some sort of middleware like passport.js that is going to underneath the hood use this jwt.verify method and use the public key to verify the jwts that are being passed through the authorization headers couple hours later and we're finally ready for our second form of user authentication which is the passport jwt strategy i think this next section is going to be really rewarding for you because we're about to take all of those prerequisite lessons that we went through whether that be the express middleware overview or you know the basics of cryptography we're going to combine those together and put it into our user authentication strategy this one's going to be fun so let's jump in the first part of this series we went through the passport local strategy and in doing so we talked a lot about the inner workings of the passport framework and in this second part since it's a little bit more advanced i'm going to be skipping over those details so if you find yourself lost for example in the process of generating and validating a username and password in a database or maybe the verify callback for the passport middleware i would suggest going back to the first part of this series and specifically just watching the configuration video for the passport local strategy now before we start to code i want to go through the options that we have here when implementing a jwt authentication strategy so we're working with the passport jwt middleware strategy but we don't necessarily need to and this is going to be the most confusing part for someone looking for a solution on the internet because there are all sorts of ways that you can actually implement a jwt strategy in your application and because of that you'll have people who understand json web tokens pretty well and they'll have their own custom strategy working but they won't explain kind of how they got to that strategy and it leaves you the reader of the tutorial just thinking to yourself well what's the actual correct way to do this and in this video i've stuck with the passport jwt middleware not because it's a hundred percent necessary but because i think it's kind of grounded and it gives us a framework to start with and then we can kind of customize on the fringes as we see fit if we were trying to be very complex about this and probably the reason you would do this if is if you were maybe trying to write your own authentication framework or you're building your own authentication server or something that you have to do that's extremely custom the most complex thing that you could do is you'd use the node.js crypto library and then pair that with your own express middleware that work together to authenticate your users now i have no interest in doing this because there's a lot of code that you'd have to write to do that but given the fact that we actually went through the process of issuing and verifying jwts with the node.js crypto library you already have a pretty good head start if you did choose to use this now the somewhat complex method for authenticating users via jwt would be to use something like the json web token npm library which is going to give you a little bit more abstraction you have a lot less things to think about when you're actually issuing and verifying the jwts but you're still left with writing your own custom middleware for your express application so that leads us to the least complex method which is what we are going to do and that is to use the json web token npm library so it's going to be really simple to issue and verify the jwts and then we'll use the already built framework passport.js and then plug in the passport jwt strategy into that framework so we have our middleware written for us but you don't need this like i said there's a lot of different ways that you can do jwt authentication the reason we're going to go with the passport jwt strategy is because it kind of just takes takes care of some of the tedious things like say air handling or extracting the token from the authorization http header like all of those things you have to write your own code for which is also going to be airprone and you've got to test it so we would prefer to kind of offload that to a framework that's already been tested and used by a lot of different use cases so that's kind of why we're starting with the passport jwt strategy but wanted to lay that out for you the last thing that i want to go through before we get into this is the basic conceptual flow of how jwt authentication is going to work now this slide right here assumes that you understand the issuance and verification process of a jwt which again was in that prerequisite video in this playlist but anyways what happens is a user is going to log into web app so we'll assume that they're already registered um they're already stored in the database our application is going to go through the basic password verification process i talked about that in the session based authentication or the passport local video but basically all we're doing is we're taking the the username that the user is going to log in with we look up that user in the database and then in the database we have a salt and a hash stored for that user then we're going to use some of the um node.js crypto library methods to actually take the plain text password that the user just passed to us and compare it against the salt in the hash that were stored for that user record in the database if the user has validated correctly based on our logic then we are going to use we'll say the json web token npm library to issue them a new jwt token now this jwt token has information about that user as well as a signature from the server itself so one of those pieces of information is probably going to be the database id of the user so then the user client which is usually a browser is going to store that jwt so back up just a second the server issues the jwt and sends it in the response body of the http request then the user client receives that http request and stores the jwt that it received there in local storage or maybe even a cookie it doesn't exactly matter where you store it it just has to be persistent storage in the browser then on every single http request that requires some sort of authentication so maybe you're trying to access a protected api the user is going to or the user client is going to attach that jwt in most commonly but not always the authorization http header the important thing is that you put that jwt in the correct header that the server is expecting and the authorization header is just the most common that you'll probably see then the server looks for that jwt in the authorization header because you've coded it to do so and it's going to use the json web token library to verify the signature of the jwt if the signature is verified we know two things we know that the jwt has not been tampered with none of the data in it has been tampered with we know that it also came from the person that we expected it to come from so if the signature is valid the server then will decode the jwt which is in base64 url encoding so all we're doing is just taking that from base64 url to json format then we will read the um the payload which is going to have information about the user so we're going to probably go for the payload.subfield that's the most common place to find this information and it's where we're going to implement it in this video and we're going to grab from that field is going to be the database id for the user so then the server is going to take that id look up the user in the database and then now it has the full user object it can do whatever it wants with that user object in our case it's going to attach it to the um express request object and then we can use it within our routes and then finally once all that has happened the user is going to have access to the resource that they requested and our flow is complete that's the process if you ever find yourself confused as to what we're doing with the code later in this video in the next couple videos i suggest that you kind of keep this you know pause the video on this slide take a screenshot of it maybe even print it out so that you know exactly the the pseudo code steps that we are going through okay so the next thing that we'll do is come back to our code and what i have open is a github repository that you can download yourself and how i've structured it is we have two branches on this repository let me see if i have it open in the browser we can just visit it there there we go so here's the repository that we that we have i just finished it up a few minutes ago but basically we have two branches to work with so the first branch that we have is going to be master and this is what you're going to have is the default when you clone this and it's going to give you a basic starter skeleton for implementing the jwt authentication strategy as i talked about in other videos my goal here is not to teach you how to write an angular app it's not to teach you how to write an express app and it's not to teach you how to use a database with express the goal here is to solely focus on the authentication piece so what i've done in this template is i've done all the implementation for all of those pieces that i don't want to cover and i've left blank the specific pieces that relate to the authentication alright so when you when you clone this and you come back to whatever code editor that you're using you'll go ahead and npm install in the base of the folder and then you also over here i'm in the angular folder so right here you'll go in the angular folder and also type npm install once you've done that then you'll go to the dot env file and you're going to enter these three variables now you don't necessarily have to do this but i guess if you're using this as like kind of a starter you'll eventually need to implement a production database string but this is going to be entirely sufficient right here and then you're also going to have to come over to this script right here generate key pair and we talked about this in the prerequisite video on public key cryptography and this is the exact file that i used in that video and all it's going to do is create an rsa public in private key pair and then it's going to save it to the current directory now our passport jwt strategy is going to use this public key pair public private key pair to issue and verify the jwts so you're going to need to generate this the one thing that i'll note about running this file if you run into an error um trying to run this then it's probably because your node.js version is not great enough i think there is some method here um i don't know which one exactly it might have been the generate key pair sync from the crypto library but it was only implemented in i think it was version um maybe 10 or something you can go ahead and find that we're in the master branch right here but in the final branch you'll see exactly how to start the app and it's it gives you the required node.js version i think it's like 10. let's go let's just verify this right now um so let's go skip over to the final branch which has the final implementation of everything and it's going to tell you that you need version 10 point x or greater to do this script right here all right so make sure that you have that set up and then you're going to just say node generate key pair and press enter and what this will do i might as well just do this right now so let's delete what i've got right here already and then say node generate key pair and you'll see in the left side here it's going to pop up in a second you should see the public and private key pair that i just created um let's refresh it there we go so we have the private key and the public key and you should be good there and then the last thing that you need to know about the setup i think hold on one second that was actually it so that's all you need to do to set up uh you also need to sorry you also need to run the mongodb database in the background um so go ahead and do that before you run the app and then when we actually run this app we're going to um it's not going to work here because i haven't implemented everything but we're going to run node app.js in the root and then ng serve in the angular application and then we're just going to visit the angular application to run the app but that angular implementation is the last video in the series if you're not interested in that then that's totally fine it's totally optional but it's just a common thing to see jwt authentication in a single page application they're pretty compatible so that's why i decided to include that last video that last optional video okay so you should be set up completely with the repository you've cloned it you've done your setup steps now let's take a very quick look at the code i'm going to perf purposely try to fly through this and i'll assume that you're going to go through on your own and get yourself familiar with what is here already but i definitely want to go through a few things here so we'll start with the express app because that is kind of the required piece let's open up app.js and you'll see that we already have kind of our skeleton app set up so of course we have express we're going to import the cores module and the reason being is because in the optional final video where we go through how to implement this with angular we're going to need to make http request from localhost 4200 to localhost 3000 so from the angular app to the express app so you're going to need this course piece in here um path just going to give us access to the um the path that we want to save things in the file system node.js and then we're requiring in passport um the dot m configuration i talked about this in a previous video but basically gives us access to um the environment variables stored in the dot env file and we access those with process dot env dot variable name so that's how you will do that set up our basic express app we're going to import the configuration for the database which is right here um just scroll through here it's basically saying if we're in production environment connect to the production string if not connect to the development string which is just running on localhost and once it's connected we should just get a little message that says it's connected pretty simple there all right so then we require in our database models which is one model and it is the user so let's open up that real quick same exact user schema that we used in the first part of this with the passport local strategy and we're just having a username and then the hash and salt will represent the password in the database then we will require in the passport configuration which is where we're going to configure the passport jwt strategy now it's a little bit weird syntax but basically in the passport configuration we are exporting a function that takes the passport object so we're importing the passport library in app.js and then we're going to pass this variable right here into the configuration function which will then receive access to that and then in the body of the function it will actually do the configuration on that object so that's kind of how that's working we'll come back to that quite a bit so don't worry about it then we will initialize passport this is required for any passport strategy you always have to initialize it so that it runs every time that you make a route request these are pretty simple just body parser middleware except now express has their own implementation so we don't have to do the body parser middleware that you're used to seeing probably so something like app.use bodyparser.json we don't have to do that because express has their own implementation now here's the cores we talked about this line right here is going to allow you to kind of combine the angular and express apps since the angular thing is optional i'm not going to go through it too much but it's going to basically if we come over to angular and type ng build it's going to build all of the assets all the static assets for that application into this public folder and then express is going to use that public folder as the um static directory so in other words express is going to use the angular build as the front end for the application all right so that's what that's doing we're requiring requiring in our routes which should just be um okay so here's a basic route configuration if you wanted to extend it easily you could just add more route files and then add you know another line here that would say something like users will say i don't know something like courses maybe you're building some sort of course module and then you would have something similar to users right here where we have all of the user routes so that's kind of how you would extend that and then in the user routes we just have a protected route which is going to allow us to test whether we did the jwt authentication correctly then we have our standard login and register post routes which is going to allow us to issue the jwt and kind of validate the jwt and finally we have app.listen which will listen on localhost 3000. so that is the basic express app that we're working with and again i would hope that you would go through this and get yourself a little bit more familiar but if you built a lot of express apps in the past this probably looks like a pretty familiar structure now in the angular app i will go ahead and save that we're not going to go through what's happening in the angular app until you actually get to the video on angular so it kind of if you're not wanting to watch that we're not going to go through it and waste your time with that i think i've gone through everything that we need to to get started with the passport jwt user authentication strategy and like the passport local strategy that we did earlier in this series it's going to follow a pretty similar structure so just like we did in the passport local or pretty much any passport strategy we're going to need something called a verify callback so in other words when we're in our routes so say we're in our login route and we pass in a passport.authena method what that method is going to do is call the verify callback that we have defined in the passport configuration so if we open up config js it's going to be defined right here so whatever we define within these brackets is what is going to be called when we use the passport.authenticate method as with any new package let's go ahead and look at some of the documentation so the documentation for passport jwt i have it pulled up right here you could also go to strategies on the home page and click passport jwt to find it so the documentation like most strategies is not necessarily uniform all these strategies are coded by different developers so it's all based on how that developer is going to put it in there so you can see here it's a little bit jumbled up but it gives us most of what we need to know the first thing that i'll draw your attention to is going to be right here and you'll see that just like the passport local strategy the passport middleware as like a framework is going to expect the same three responses so if our callback returns some sort of error whether it be a database error or an express application error we pass in the done callback with the air parameter as the first parameter and then false for the user object then if we successfully authenticate the user we say that there's no error and here's the user object which will eventually be attached to the express request object and then finally if there is no error within our application but there's also an invalid user then we're going to say there's no error but there's also no user so these three responses to this verify callback is how passport knows what to do all right so now we got that covered let's look at some of the options that we're going to be dealing with when we're using the passport jwt strategy so as we know we're going to call passport.use and then we're going to pass in a new some sort of strategy in this case it's the jwt strategy and then that strategy is usually going to take options first and then the verify callback so those options here are going to be defined up here at the top and i will note that most of these options are related to the json web token npm library so if we open that up here's the json web token library this is actually what the passport jwt strategy is using to verify our jwt so all of the options that you see here so there's some examples here's the jwt dot verify method this is exactly what the passport jwt middleware is using and all this strategy is doing is passing in the token that it receives it's going to pass in the secret or public key so there's multiple ways that you can verify we're going to be using the public key since we're using asymmetric cryptography and then we have the options object which is literally going to be just passed straight through to this method from the passport middleware so you see down here we have all the options that we can put in here algorithms complete issuer ignore expiration all of these you'll also see well not all of them but you'll see most of them listed here in the strategy documentation now the way that we actually include these options is a little bit tricky and i actually could not based on this documentation figure out how to get all of these option passed to the verify callback so what i've done is just put together every single option that you could possibly ever need and i've put it in a single options object and then we'll kind of reduce to the only the stuff that we need going back to our code let me just paste in this like all-encompassing options object and i might as i might even leave this in the final implementation just comment it out but here is the full options object if you were to pass in this obviously you need to replace some of these things with valid values but if you were to pass this in it would be readable by the passport jwt middleware so you'll see at the bottom we have the json web token options and this is where it gets a little confusing because here are some of those json web token options that we saw in that library's documentation but there are also options from json web token that are that are passed up here and if you were to pass these down in the json web token options the passport jwt middleware as it's implemented would not actually read them correctly so it's really important that you put the options i have listed here exactly how you see them if you see them in the json web token options they need to stay there so that is the entire all-encompassing option object but we don't actually need that i'll go ahead and put this in the final branch of this repository but i'm going to delete it out for right now and we're only going to work on what we need the very first thing we'll do as with any module is import it so we need the passport jwt strategy and we're going to extract the strategy off that so that's going to be a class and then this extract jwt class which is basically a little subclass that is going to give you options as to how you extract the jwt from the http header if you look at the documentation online you'll see that this is detailed at the bottom so in the section extracting the jwt from the request this just has to do with that process where the server needs to know how and where that jwt is stored in the request usually it's going to be in the authorization http header but it isn't always there so this gives you some options as to where you can find this so we're going to just be using from authheader as bearer token this is probably one of the more common ways to do it but you could also pass it into like a post request body field you could put it in a url query param and if you were to do that you would use these different methods from this class you could also write your own extractor function so i know i mentioned earlier that you could put the jwt in a cookie and this right here just gives kind of that example this is how we would grab it from a cookie and so you can kind of have some freedom to implement whatever you would like so our options object is going to be pretty simple just going to replace this right here and this is what we're working with so this is the options object that we're going to need to implement the jwt strategy first is what we just talked about the extract jwt class comes with different methods for finding that jwt and parsing it so we're going to use the from auth header as bearer token so in other words it's going to expect that we have our jwt sitting like this so here's our authorization header and then we're going to say bearer and then a single space and then here is where our token is going to sit so it expects this exact syntax and if you were to maybe take the space out or just delete the bearer portion completely it's not going to be able to read it correctly you'll see how that works a little bit later the next thing is the secret or key property and you can either pass in a symmetric or key which would just be a secret that you stored in an environment variable but for us since we're using the rs256 algorithm to issue and verify jwts we're going to pass in our public key that we generated with that script right here and we're reading that from the file system it says path to key id rsa pub and the reason that we're passing in the public rather than the private is because what we're configuring right here is the verify piece of the jwt so if you remember we have the issuance and then the verification with a digital signature we sign the issuance with the private key and then we verify the identify or we verify the identity with the public key so that's why we're passing in the public key because passport is the verification step of this process then finally we're just passing in the algorithms that it will accept and we should be done with it so that's our options object obviously we didn't include half of the options that were available to us but i just wanted you to know that those were available in case you were doing something a little bit different than me like i did with the passport local strategy i'm going to kind of deconstruct this configuration so that you're not just looking at a big blob of you know callback functions and options and all that stuff so we're going to keep it as modular as possible here the first thing that we do we have our options object already configured but we need to use the well jwt strategy right here so we're going to say const strategy equals new jwt strategy all right so that is going to take two arguments one being the options object that we defined right here and two being a callback function which is going to it's already telling us what it expects so it's going to take a payload and a done callback all right so that is the basic implementation right here and then we're going to actually configure it by saying passport.use strategy so again this passport object is being provided from app.js then we're taking that object we're saying use so similar to a middleware and then we're passing in the strategy which has the options configuration in the callback function or the verify callback that we are about to implement within the callback as i mentioned with the passport local strategy the great thing about passport and also the confusing part is you don't have a specific way that you're required to verify in authentication and in our case we can use whatever database we want we can use whatever you know code logic we want to do now since we're using mongodb we'll just use the find one method on the user model so we've imported this from our database configuration so we'll just say user dot find one and then we're going to pass in the id and where are we going to get this id from well if you remember from previously in this i think is in the first video we talked about how the jwt payload so the second part of a jwt is going to have a subfield well in our case it has a subfield and in many cases it has a subfield that will include some information or unique identifier about the user in our case when we implement the register and login functions or the routes we're going to issue a jwt and we're going to place the mongodb database id in the subfield so here's our payload this is in javascript object form so we can literally just say payload dot sub and that's going to pass in the id that we need to look up our user in the database we will then use promise syntax to grab the user and then we will catch any errors that happen and if you remember we need to pass in the error to the done callback if we um and no user if there's an error within this operation so the last thing we need to do is something in this area where we have access to the user that we just looked up now if you were watching the passport local strategy you'll probably remember that in this area we were doing all sorts of stuff we were verifying um you know using a crypto function we were verifying the username and password well in this jwt strategy it is much much simpler we are just we've already validated this jwt so this strategy has already gone through the process of using the json web token library to verify the jwt that it's received so at this point when we're sitting right here we already know that our jwt is valid so all we have to do is check if we found a user in the database and if we did we need to return it to passport so that it can attach that to the request object so we'll just say if there's a user we will return done and there's no error but there is a user otherwise we're going to return done and we're going to say no air and no user excuse me this is not null this is going to expect false so passport expects to see either a user object or false so that is the implementation that we need to do for this verify callback it seems like nothing really is happening but behind the scenes the passport jwt strategy is taking these options it's grabbing that jwt from the authorization header it's validating that jwt with the json web token library then once it's validated it it passes the payload object right here then we grab the id of the user from the payload sub object look it up in the database return it to passport and then passport attaches it to the request.user object within the express framework so that is all that we needed to do to implement passport jwt now i would try this out in the browser and you know see if it's working so far but the problem is we haven't issued any jwts so we could go generate a jwt or grab an example from online and see if it would work with this but it never will because we have generated exactly zero jwts using the private key that we generated in this repository so in other words when passport jwt strategy tries to verify the jw jwt we've included in the authorization header it's going to reject absolutely everything because there is no jwt in existence right now that corresponds to this private key so when we verify it with the public key it's just going to reject it so what we need to do is write some logic in our login route so that every time a user logs in we're going to issue them a new jwt that is signed with the private key that we are using from this server then the passport jwt middleware will use the public key that resides on this server and will successfully verify these new newly issued jwts so to do this we need to come to the routes so we're in the routes users.js file and the first thing that we'll need to do is the register function so if a user is going to come to our application they obviously need to first register and basically what's going to happen in both of these routes is we're going to issue a jwt regardless so the way that this flow is going to work is if a user comes to our application and has never been there before and registers they're just going to provide their username and password then we're going to store that new user in the database and issue them a new jwt and then we're just going to consider them logged in for as long as that jwt is valid and then the login is also going to issue a new jwt but it's just going to look up the existing user in the database and validate the user the username and password that that user put in there when they registered if you watch the passport local strategy videos you're going to be very familiar with what i'm about to paste in so what we're doing here in the register function is we are taking the plain text password that the user has provided us with and we're creating a salt in a hash based on that plain text password we're just using some crypto utils so if we go in lib you'll notice that these these two functions valid password and gen password are going to be the same exact um generation and validation functions that we used with the passport local strategy and so you might ask yourself for a second well wait a second isn't this jwt isn't this a jwt strategy like why are we working with like username and passwords and all that kind of stuff well you have to remember that the jwt is simply a result of a successful user authentication with a username and password so whether you're using the passport local or passport jwt authentication you're always going to need to know how to store a password in the database and then verify it out of the database i'm not going to go through that if you wanted to really understand how this works i do have a slide on that let me just pull it up really quickly so here is the basic password validation process since i talked about it in the passport local strategy a lot just go watch that video if this doesn't make sense otherwise just read through this really quickly all right so that's basically what's happening with the password generation and verification and in the register function we're doing part one of that so we're going to create the salt in the hash and store those in the user record in the database then we'll save the user in the database and just return a success message as well as the user object now i also mentioned that we're going to be issuing a jwt here which we will do in one second but i want to first look at the function that is creating that jwt so we go to the bottom of the utils and you see that we have exported this issue jwt function which is defined here and since the passport jwt middleware is using the json web token npm library we might as well use the same library to issue the jwt so what we're doing is we're taking in the user object that we have in the database we're going to take the id of that user in the database and we are going to assign it to a variable here we are going to say that we want this jwt to expire in one day usually you'd probably do this like two weeks or something but we're just going to do one day for now and then the payload of this jwt is going to be defined as the sub property we'll have the id as we talked about when we were configuring the passport object and then the issued at will just be whatever time stamp is right now then we will sign the token and we're going to do that using the dot sign method of json web token library we're going to sign it with the private key we imported this up here at the top so here's the private key that we imported and that private key corresponds to the public key that we're going to verify later with then we're going to pass in the expires in value and algorithm that we plan to eventually verify it with and that we will sign it with so once we've signed the token we will return a token which has the bearer string at the beginning and then the sign token and then the expires in property so we have this function that's going to issue a new jwt signing it with the private key living on the server and then we're going to come back to our users routes and then in the success message we're going to attach a token and then a expires in property and to do this we just need to um well actually we're going to want to do this down here because when we initially create the user we don't have the id that was stored in the database yet so we need to come down here in the callback to get that id so we'll say the id is equal to user dot id and then we're going to issue this jwt so i think i've already included the utils library so we've got the utils library up here so we're going to say the jwt is equal to utils dot issue jwt then we're going to pass in the user and actually i don't know why i did this right here the function itself is going to grab that id off of the user object so all we have to do is pass in the user and then if you remember it returns us an object with a token and expires property so we're just going to grab the jwt dot token and jwt dot expires and there we go we have a successful response and once we have saved this user in the database after registering the front end client will get this message right here so let's do that really quickly let's run this make sure that we don't have any errors going on looks like the database connected okay and i'm going to open up postman which is just an http um request application it's got a lot of other stuff i should probably be giving it more credit than that but let's go to register i've already got the post request set up and in the body we're just going to require um i think it was just a username and password so we'll say the username will be zach we'll say zack jwt just that we can distinguish from the passport local strategy i was doing in a previous video then the password will be just one two three my default debugging password here so i think that's all that we need for this request let me just check that really quick okay so this is all we need we should be able to run this and hopefully it works um let's see what we got for the response looks like we had some issues so let's go back and see what's going on um hmm oh of course we have the wrong route that we're using i just said register it's actually going to be i think users slash register or even maybe even api slash users we'll find that out real quick come back to the code let's look at our index.js okay so we're going to okay so it's the slash users route is what we're going to need so come back to postman get rid of this api we didn't include that now we should be able to send it and we get a successful response so here's our response success is true here's the user that we stored in the database and we'll verify that in a second and then here is the token and the expires in that we issued using the utils library that we wrote all right so this is what the frontend is going to receive as a response and then they're going to take this token and store it somewhere in local storage so that it can attach it to every single request in the future implementing the login post route is a little bit more complicated but i'll post in the implementation or paste in not post i'm looking at all these post requests and what we're doing it's it's pretty simple but there's a lot of code here so we'll start at the top the first thing that we're doing is we're going to take the username that we received from the login form whatever the user typed in and we're going to look in our database for that username if we then will assume that we find the user and we populate it in this user property we'll say first if there's no user so if this user in the database doesn't exist maybe this person is trying to log in and they haven't even registered we'll just return a 401 code with a message that says could not find the user pretty simple there this next line if you watch the passport local strategy you'll understand this exactly but if you didn't what this is doing is using that valid password function so up here the validate password function and it's basically going to check okay is the username um that you just gave me and the password you just gave me are they valid so it's going to take that plain text password that the user just typed into the login form and validate it with the node.js crypto library and that function that we already defined so this is going to either be true or false based on whether the user logged in successfully and mind you this is different from the jwt remember we have not issued the jwt yet we'll just assume that they're logged out so if this is valid we know okay this is a valid user we need to give them a jwt that they can attach to all of their future requests so that they don't they don't have to log in every single time so here's our issued jwt it's exactly how we issued it down here and then we will attach that with the same exact response body that we did earlier we also probably should just put in the user property here like we did in the register route and then finally if the user did not log in successfully they gave us the wrong password or the wrong username whatever then we will return this response where it says you entered the wrong password and it's just going to be a 401 response because that is like the unauthorized http code all right and then we're going to catch any errors just put it through standard express middleware and catch it in our air handler i don't even think we have one implemented for this but that's kind of what that's going to do all right so we've got both of our routes implemented and let's come back to postman just make sure that this is going to work alright so we'll go to login and let's just copy the body that we put for the register because it should be the same so here's the user that i already have registered in our database um here's the correct password for that user let's make sure that we have the right path here and click send and we get a success is true and we get the same exact response here is our jwt that we will store in the browser at some point all right so we are done with the bulk of our work here the last thing that we need to do is just test to see if our passport jwt middleware is working correctly so far we haven't even tested the passport jwt middleware we've just be been doing the basic username and password register and login and issuing the jwt all right so coming back to vs code the way that we're going to test this is in this first route which is the protected route and we are going to pass in the passport middleware right here so we'll say passport.authenticate and then we're going to say that we want the jwt strategy and we're going to pass in an object that says session false and the reason that we do that if you're familiar with the passport local strategy that we did in previous videos we were using the passport session middleware to actually interact with the express session middleware but we're not using this here because we're using jwts so we say that that's false all right so what this is going to do is execute that verify callback so this function right here and if we successfully validate the jwt that has attached the request it should let us into this route so we should be able to print something let's see if we can get in here all right so we'll just say res.status200.json.com will stay consistent here is true message is going to be you are authorized we are now ready to test this out so let's go to pat to postman and we'll come over to the protected route again we need to put in that path and here's where the magic comes in but also kind of gets really confusing we have to attach the jwt that this user owns to the authorization header now in postman you have the option to put it here in the authorization tab you could just do bearer token and you put the token here but we're not going to do that we're just going to stick with basic http headers to keep things simple so we're going to use the authorization header and then the value that we will pass in is that token that we received over when we registered or logged in so we just logged in so we're going to take this entire token including the bearer portion and we're going to copy that into the value right here so this value because it's in the authorization header and because it says bearer with the space and then the token which is exactly what the passport jwt middleware is expecting that middleware is going to take this value it's going to run it through the verification function using the json web token library and hopefully authenticate us correctly so we're just doing the get request let's send it and it says success true you are authorized so in this case we just copied in the bearer token here the jwt in postman but obviously if you're implant implementing an application you're going to do this on your front end client so for example angular and you're going to want a way to you you'll probably store it in local storage after you've been issued this and then you will write some sort of logic to attach it to every request but that's not the purpose of this video this video is just to show you how to configure the passport jwt strategy so if you wanted to watch that that'll be probably the one of the next videos or something like that but the last thing i wanted to do in this video is just kind of a quick recap to show you exactly how you're going to be using this alright so every time every route that you want to protect using jwt authentication you're going to use this syntax right here if you wanted to simplify it even further you could probably write write yourself a middleware that just calls this method and then you only have to pass in like a couple letters but if you wanted to you can pass in this exact syntax every single time now this is very different from the passport local strategy because if you remember when we did that if you watched that video we only called the passport.authenticate method one time and we called it in the login post route and then after that what we were doing to check whether this user was authenticated was saying if request.session.passport.user exist or i think we had a shorthand method if request dot is authenticated that's how we were validating whether a user was logged in but since jwts are by default stateless we're not using sessions we have to call this every single time so that the passport middleware can you know grab the jwt that's included in the request and verify it so it's pretty simple actually this all you're going to be using attach it to every request that you want to authenticate and you could even come over to your passport verification and have some sort of different logics you could say in this part of the body you could say if user.admin if you wanted to validate like an admin property or something you can get pretty creative with it but that is the basics of using the passport jwt strategy i just want to take a few moments to say congratulations if you've made it to this point the remainder of the video is completely optional for you you can fully say that you understand the basics of user authentication in node.js express and passport.js if this video has connected the dots for you in one way or another i'd really appreciate if you went and checked out my channel um much smaller channel than the one that i'm on right here but i make a lot of web dev related videos and post on a weekly basis at least at this point so go check it out subscribe like a video that would be extremely helpful to me and i'd really appreciate it alright the last part of this video as i said is completely optional and we're going to be covering two things number one we're going to be covering how do we actually take passport js out of the equation with the jwt strategy believe it or not the passport jwt strategy is just using the json web token library under the hood and we can do the same thing well passport js has a lot of strategies that really alleviate a lot of the work that you would have to do and i'd highly recommend using them the jwt strategy is a little bit unique in the fact that i don't think that the passport jwt strategy adds a whole lot of incremental value to you now that is of course if you understand what you're doing and since we just talked for many many hours to learn how all of this works and we actually do know what we're doing we can implement our own jwt strategy pretty easily and then in the final part of this video we're going to walk through the basic implementation of a jwt strategy with angular on the front end now of course this will not apply to all people not everyone is an angular developer or has an interest in that but i did want to tack it on to the end in case you are working within the angular framework and are confused how do you take all these concepts and translate it to you know the front end and use local storage to keep your users logged in and communicate with the backend that we just wrote all right let's go ahead and first jump into how do we write our own custom jwt authentication strategy so what you see on the screen here is our application it looks a little bit different got a slightly different environment as i'm recording this video which is kind of recorded a separate time as an addition to this course so everything is the same though don't worry about that let's go ahead and open up postman just so that i can prove that out to you so if we go to the register route we'll put in another test user and we'll send that request and it's not going to work because we're not actually running the server at the moment so let's go ahead and run the server try that again and we should get a successful creation of the user now let's copy these same credentials oops we'll copy the same credentials into the login right here click send and we should get a bearer token let's copy that bearer token go to our protected route and drop that into the authorization header value click send and it says you are successfully successfully authenticated to the route so as you can see it's the same exact thing nothing has changed but what i want to do now is close out of here and i want to create a new branch so we're going to create a new branch called custom jwt and what we're going to do on this branch is we're going to completely rip out the passport js implementation and add in our custom jwt implementation you might think that sounds really difficult but it's actually not and although there is a really good use case for passport passport as a middleware and framework such as the local strategy and a lot of the delegated authentication such as you know the social logins truthfully the passport jwt strategy does not really do a whole lot of heavy lifting for us quite honestly i prefer to do my own custom implementation when working with jwt so the most obvious place to start is going to be in the passport.js file where our implementation sits let's take a look at what we might have to change so the first thing that i see in the options is that we have this method called extract jwt from auth header as bearer token so we need to be able to take the off authorization http header and grab the correct token and parse it in our code as i mentioned earlier passport js is doing that for us so we don't have to do it on our own but as we're ripping passport out right here we're gonna have to write a custom function to do this furthermore in the main implementation this is just a middleware so we're just going to replace that with our own custom middleware function that's all it really is is just a function and we're basically going to verify the jwt that is passed through the request and then you know either authorize or deny access to that given route and then that's going to play out once we go to the routes over here where you see in the protected route we're using this passport.authenticate method we're just going to replace that with our custom middleware function that we're about to create so just to start us off let's go ahead and and start removing some things so let's comment out the passport declaration up here and let's also remove the authenticate method right here and see how that changes everything for us so we should still be able to start the application and then go over to postman go to the protected route and we can uncheck this authorization and click send and it says you are successfully authenticated now that's obviously not true because what we did was just remove the middleware that's authenticating us so we need to replace this with some other middleware and we're just going to throw this in the utils file because we've already got this being imported so let's open up utils and you can see we have a lot of our helper methods in here and what we can do is actually create our authentication middleware as well so let's go ahead and create a new function and we'll say this function will be called off middleware something like that and what we need to pass in as with any middleware is going to be the request object the response object and next and then of course we're going to create that as a function so we'll drop it down here by default let's go ahead and just send a 401 unauthorized error so the 401 http status code is for unauthorized and if we were to um let's save this go back to our users right here and add back in the passport authenticate method and then uncomment or yeah uncomment the passport import this is going to put us back to where we were and if we go to this protected route and we've got the authorization removed and click send we should get this unauthorized response and if we click through this let's see we can look at the headers and it says the status is 401 unauthorized and then it explains that error similar to 403 forbidden but specifically used for when authentication is possible but has failed or not yet been provided so that's a good just overview of the 401 error and we can also see that we're doing this in the res dot status right here uh in the login route so we're already a little bit familiar with this but by default we're going to make this off middleware just send that 401 and maybe we can even stay consistent with our login so instead of just sending it we'll say res.status and then give it a payload or a response body so we'll say res.status is 401 the success is false and the message is going to say you are not authorized to visit this route from this point let's go ahead and copy one of these down and replace our export so that we have the off middleware export so that's going to export it from this file and now we can actually use it over in users.js so we've got this import already so let's let's comment out passport again just that we're not we're not importing that anymore and we can we can go ahead and delete that because we're not going to toggle that back on yet or anymore so we'll go to utils.off middleware and that's really all you have to pass in you don't have to pass in any you know parameters or arguments or anything so let's go back to postman and try out our protected route so let's click send and see what the response is we get a success false you're not authorized to visit this route and the reason we're getting that is because when we run this route instead of getting what's in the body of the route we're passing through this off middleware that we just created and it's by default giving us an unauthorized status but that of course is not what we are wanting to do here we're wanting to get the jwt that was passed into the request and then pull out the token from that and validate that token using the json web token library because after all that's all that passport jwt is doing in the end what i have pulled up here is actually the passport jwt strategy implementation and you'll see that on the verify jwt this is all that's happening you're just using the json web token library to verify the token itself so that's not going to be all that difficult for us to do and then furthermore we have the extract jwt which is going to be if we come back here go to passport and see this method right here so the from off header as bearer token so if we were to go to that same repository we can go to the um off header or no the yeah the offheader.js which is going to have a parse offheader method which is going to basically call the extract jwt and then this has a bunch of different ways that we can do this depending on what our header looks like but in our case it's from auth header as bearer token as we saw right here and what that's doing is calling another method which has some utility functions so on and so forth so that's not all that difficult to implement either let's go ahead and see what that request header looks like so if we were to drop into the off middleware in console.log the request and then i believe we can just say the request.header if i'm remembering this correctly and then we came over to postman and we went to the headers turned back the authorization header and click send and then we'll see something printed here so maybe i did not uh print this correctly so i'm printing a function not the actual header so i think i have to say request.headers maybe instead so let's go back send this request again and now we're getting something a little bit better so we're seeing our header printed out now let's go back to postman and instead of this authorization header let's go ahead and copy the token itself and turn this one off and then go to authorization and click bearer auth so if we copy in this token and click send we should still get the same header so we we're always going to get this authorization property and that's kind of what it means when we're looking at the passport implementation and it says that we need to extract jwt from the auth header as bearer token that is us telling the passport library hey we expect this certain format so parse it accordingly so that's basically what we're saying is we always expect this exact format to be passed in and in our utility method we're going to have to take that into account so the next question is how do we actually parse through this token well we can actually split the token because as you see in the format down here there is no spaces other than between the bearer and the token itself so if we have a valid bearer token we can just split it with a javascript method so let's go ahead and make a variable called token parts and then what we're going to do is we're going to say request.headers.split and we're going to split it by a single space now if we console.log the token parts instead of just the entire header you're going to see something that we can work with a little bit easier so let's go ahead and remove this we'll go back to no off because i think it's a little bit more straightforward when we're just passing in the authorization header and let's go ahead and click send and it looks like we got some issues here it says request.headers.split is not a function and that is of course because i'm not thinking at all trying to talk and teach and code all at the same time it's a little bit difficult sometimes i don't want to split the headers i want to split the headers.authorization property let's try that that might work a little bit better and this time we should get an array so our array has the bearer and the token keywords and then from here we basically need to check to make sure that this is the correct format because what if what if we get something that's incorrectly formatted passed as an authorization key that would obviously be invalid so what we're going to do here is we're going to say if the token parts 0 is equal to the word bearer which is what we would expect and the token parts number one so the first index which would be the actual token if that matches a certain regular expression then it's going to be valid in that regular expression as we learned with the jwt portion of this course is always going to be a series of characters with a period and then another series of characters with another period somewhere here if i can track it down and find it so right here is the second period and then some more characters to follow so the way that we can validate that is with a regular expression that basically just looks like characters period characters period more characters if it doesn't follow that format then it's invalid we don't want to let the user into the route so we can actually use the string matching function and we can pass in a regular expression that i've already written so this course is not about regular expressions so you're just going to have to take my word on this this right here is going to basically say look at the string that we've got down here and ask you know whether it fits that format of characters dot characters dot characters and if it is then it's not going to equal a value of null so if it does match then it's going to give you a results array if it does not match it will return null so if we check and make sure that that does not return null then we know that we have a valid jwt format so we're basically saying if we make it into the body of this if statement then our token is valid we are now ready to actually write the verification portion of this with the json web token library now we've only imported our private key up here but we also need to import the public key in order to validate this so remember we sign it with the private key and we verify it with the public key so that's the order we're going in so let's go ahead and copy this down and we're going to grab instead of the private key we're going to grab the public key and then we're going to change the variable name copy this down change private key to public key and update the variable here let's make sure that we're getting that correctly first so if we get here and we have a valid token which we should we should be able to console.log the public key constant variable so we restarted let's try to visit the protected route and you can see that we're getting that public key printed out just fine so that's working now we just have to implement the json web token verify method that it comes pre-built with so if you were to go to the json web token documentation on npm and search for the jwt dot verify method you can see that it takes in a token which is going to be the jwt a secret or public key so that will be our public key and then of course we have some options and a optional callback function you can read through this but i'm going to go back and just implement it and show you exactly how to use it so we've got the imported json web token library and all we need to do is come down in here and say let's say verification variable equals json web token dot verify now it's going to ask us for a token which we're going to give it the token parts at index 1 which is the actual token we're then going to pass in the public key and then in the options it asks us whether we want to supply an algorithm so if i were to go back to this documentation we have an options and algorithms which is a list of strings with the names of the allowed algorithms for example hs256 blah blah blah so all we have to do is pass in the algorithms and then in the array we need to pass in rs 256 and you might ask how did i decide on that algorithm well if you remember from the passport.js file where we were given the options to the passport middleware we were basically saying i want to extract it as a bearer token which we did here in these lines right here then what we said is i want it to be using the public key so we passed in the actual public key just as we did right here and then finally we said that we wanted the rs256 algorithm which is basically the public private key pair or asymmetric cryptography so that's what we're doing here in the algorithms section so we're basically giving it the same options we're just doing it more directly so let's go ahead and console.log the verification and see what we're getting so let's go back to our postman if i can get there and click send so we sent the request we'll come back here and we're getting this value right here which is going to basically be an invalid value if it was not successful or will get this object if it was successful so let's go ahead and manually put in the wrong key to see what happens if it's not so we'll just remove this first e at the beginning of the bearer token and click send and now we're going to go back to our library here and it's going to say json web token air invalid token as you can see here this has thrown us an air and we don't want that in our application we want to handle all of our errors and if we were to go back to our documentation here for this method it's going to give us an asynchronous way to do it and a synchronous way to do it let me just get rid of this search so we don't see that and for the synchronous method it says if a callback is not supplied function acts synchronously returns the payload decoded if the signature is valid and optional expiration audience or issue issuer are valid if not it will throw the air so that's basically telling us that we need to handle an error if we're doing it synchronously which is how i want to do it here just to stay simple so we can use the built-in try catch block so we'll say try catch and then pass in the air and if we go ahead and run this method right here if i can copy it correctly if we run that right there it should pass and if it if it does not pass it will throw an error and at that point we can console.log the error just to see what we're dealing with so let's go ahead and see if we can verify it so basically if we don't make it to the error state then we know it was successful so we've reconnected let's send the request with an invalid request and you'll see that we have printed out the air now so it looks like it through the air but we're actually just printing it and handling it gracefully so based on this all we need to do now we've just kind of tested everything out let's get rid of this console log statement let's also not print a variable that we don't have anymore that's a problem and then we'll come down into the catch block and if we have an error that's where we're going to put this status of 401 so as of right now if it was successful it's not going to do anything it's not going to return anything if it's unsuccessful we're going to get this message right here so if we go back to postman we should expect to get the you are not authorized to visit this route message which is what just happened so that's working great and now what we need to do let's go ahead and assign this to a verification variable once again and now what we're going to do is pass the next callback in here so we'll just say next and that's going to pass us through to the next route at this point what we could do is we've got this verification stored and let's go ahead and console.log it one more time just to see what we're dealing with and at this point i need to add back in that uh e character that i just manually removed from this token so now it should be valid and when we send the request we're not going to get any response yet because we haven't done anything here but in the terminal if we scroll to the bottom we should get this little block of code which is some useful expiration date of the jwt token which we can then use on the front end to you know set expires headers or expires in local storage and stuff so it would be helpful to pass this along so all i'm going to do is say on the request object i'm going to going to assign the jwt equal to the verification and then i'm going to say next to pass it to the next middleware in the chain so at this point we're passing it to the next middleware in the chain and now we have this jwt property so we're going to drop into this route and now we should be able to console.log the request.jwt and if we console.log that successfully then we know that it was a successful verification and we should see the same object being printed despite the fact that we're not printing it in our middleware anymore let's go back to postman click send and it says you're successfully authenticated which is good good news and you'll also see this jwt that we had attached to the request object so believe it or not we are done ripping out passport.js and implementing our own strategy so if we were to come to the passport.js file and just click delete on this whole thing we should still be able to run our app so let's start it it's going to crash because we're currently importing that into app.js so if you remember we're configuring passport right here and do we do anything else yeah we're importing passport up at the top just want to make sure we're not using it anywhere else let's save that and see what else looks like i missed one so on line 22 here's the initialization call we'll delete that out click save and it looks like we're compiling correctly now we've deleted passport entirely i don't think that we have any other references to passport let's go ahead and check so that's just in the package json and then the readme so we're looking good we have no more references to the passport library in our code and now we should be able to go through the entire flow that we went through previously with our custom strategy so let's go ahead and try it we'll start with the register route we'll put in a new user click send we've created the new user we will update our login route to log in our new user we'll click send there we've just been issued a new bearer token and then we'll come to the protected route copy in the bearer token and click send and it says you're successfully authenticated if we you know delete some stuff here and pass in an invalid bearer token and click send it's sending the request and not returning anything for some reason and i've actually got an error in my code that i forgot to account for because it's not returning a request so the reason that's happening is because remember we're verifying whether this is a valid token in the first place and only if it's a valid token are we trying the verification so we need to provide an else statement to catch any time where the the actual syntax of the bearer token is wrong and we'll return the same unauthorized status if that's the case so now if we come back and click send we should get an unauthorized response so i'm glad i caught that but basically that's just a demonstration of how we implement our own custom jwt strategy and it's what i use in a lot of my apps for when i'm just getting started and you know providing a basic authentication strategy once again you can check out the github repository associated with this course and go to the custom jwt branch to see the code that i just worked on and last but not least let's go through how do we implement this jwt strategy on the front end and sync it up with all the code that we've written on the back end in express today we're going to be talking about how do we take the passport jwt strategy that we implemented in our express application and kind of port that into a frontend that will handle the jwt and attach it to each of our http requests so we're going to do this with angular and the reason being is because i for one know angular better than most of the front-end frameworks and number two it is very compatible with jwts now if you were to um let's say make an express app and you used ejs as a templating language and that's how you built your front end now in that case sure you could you know somehow implement a jwt front end but it's going to be a little bit more difficult because the pages that we would be loading on the front end are going to be coming straight from the server well as in an angular application it's an spa or single page application which means everything happens in the browser so that includes the um the jwt stuff and so it's just very compatible for what we're doing here like i said in previous videos the goal of this one is not to teach you how to write an angular app so i'm assuming that you already know kind of the basics of angular we're not going to do anything too crazy but i'm not going to be walking you through the structure of how angular works and all that good stuff the goal here is to show you exactly how we take our express server that is issuing us jwts and translate that into the front end so to do that i want to first walk you through what i've already provided you with in the previous video i introduced the github repository it'll also be in the description here and when you download the repository on the master branch you're going to have a blank template we implemented the first part of that template in the express application in the last video and then the second part of the template is what we're going to be doing in this video and that is sitting in the angular directory and if we open up the main part of this application you'll see several folders already built for you and they're all connected up so this app kind of runs already even though we haven't implemented the actual methods so i'll walk you through it real quick let's start an app.module let's see what we've got here so i've already set up the routes for us so if we visit login register and protected it's going to load the login register and protected components so that's already set up for us in angular kind of gets that out of the way we are declaring those components here let's see here's the router module and this is important we have to implement the use hash option because we have our api from the express application and then we have the routes from the angular application and we don't want those to conflict now down here i kind of debated whether i was going to put this in here but this is the setup for our http interceptors and that is something that we're going to actually implement but i've left the the structure of it intact and it's already included in the main module so you don't have to worry about doing that but this right here is a very special syntax you're probably not used to seeing it if you don't work in angular a lot so that's the app module which is the base of the application app component just has three links so that you can load each of the routes and then i actually put the routes below so we're pretty much staying on one page the whole time and just toggling between the routes by clicking these buttons up here i can go ahead and run this just so we can see what that looks like i don't think we should get any errors so it loaded successfully let's visit in the browser and you can see that our application is very far from beautiful the goal here is not to style it up or anything we just want the functionality so as i said if you click each of these routes they're going to display below so right now we're at the home route so nothing is being displayed but if we click login you'll see a little ugly login form if we click register you'll get the register form and then the protected route is just going to give us a message and in this case we don't get a message because we're not authenticated so that's kind of the the entirety of this application obviously it's not something that you would show to any user but it does give you the setup and the the logic behind how you would start an application okay so let's come back to the code walk through a couple more things that we've got set up and i'll kind of show you what we're going to be doing in this video so the first thing we've got is the off service this is a service that we're going to be spending a good amount of time in as you can see we've got five different methods that we need to implement in order to kind of manage that jwt that was issued from the express server next up we have an auth interceptor which we have to implement the intercept method for this what this is going to do basically is take each http request and it's going to attach the jwt to it so this is kind of the magic behind the scenes then of course we have each of our components so the login protected and registered components let's see what i have implemented here we we basically just have the form functionality implemented so we don't have to walk through that logic so you see here we have a register form then when we submit the register form it's going to call this method which sits right here and in this on register submit we're just going to take the username and password we're going to make a post request to our express application which is on localhost 3000 and then we're going to get a response and if it's successful then we're going to navigate back to the login so don't worry too much about what's going on here this is basically just making the request to get the jwt from the express server and then same with the login you're going to see something very similar you have a form here you have a method on submit and that method is going to make a post request to the login route of the express application so go ahead i know i didn't cover absolutely everything so go ahead on your own time and just pause the video and take a look through this angular app just get familiar enough with it and then we will get into actually implementing the jwt um strategy here i think the first thing that we should do is implement this service called off service now this is going to manage how we store and retrieve the jwt token or jwt that we have been issued from the express server before we do that though let's go and quickly review what we're getting from the express server so if you remember from the last video when we register a new user let me go ahead and register a new user real quick we send that oh and it's not going to work because the express app is not running yet so we need to first run the express app okay express app is running we can go back and actually let's how do we cancel this request um cancel all right so let's send it one more time this time we should get success true and here is our jwt so this is how we're getting information from the express server and then if i wanted to log in with that same exact user i could do that with the login route and it's going to give me the same exact data so this is the data that the angular application expects and once we get that data we're going to basically take this token and put it into local storage so that is what this auth service is doing it's basically saying okay once we get the response we want to set local storage then the logout method will basically delete stuff from local storage so on and so forth to help us out and kind of keep things straight um in our heads i'm going to copy in this response that we get from um the express application when we register or log in a user so i'm going to put this here and just comment it out so that we have a representation of what we are expecting to receive and this when we implement this first method here the response object should be this right here so the first thing that we need to do in the set local storage this is going to be when we receive our jwt and we need to put it in local storage so the first thing that we need to do is actually figure out when this jwt expires so in the response body up here we're going to get a value of one day to make things a little bit easier and not have to deal with javascript dates and stuff we're going to use a library called moment.js which is here's the documentation for that and it's pretty simple to be honest moment is the main function gives you the current moment and then you can do whatever you want with it you can format it here's like the live on the right side here is like the live updates to these pieces of code you can also do things like add certain amount of days so this is what we're going to be doing we're just going to be doing moment.add and then pass in that 1d which represents one day so come back to the angular application we're going to just store let's say expires equals moment dot add and then we're going to say the response object dot expires in alright so we've got the response object right here and then the expires in property so basically this right here equals 1d and if we add that to the current moment that's going to give us the time that this jwt expires after we've figured out when this jwt expires we need to set two things into local storage to do that we can just say local storage dot set item and this set item method is going to take two values so first is the name of or first is the key and second is the value so we'll say token is the key and then the value of that if we look up in the object that we should be getting here it's going to be dot token so we will say response object dot token and if you remember that token is has the bearer included so just keep that in mind as we go forward local storage dot set item and expires so that's going to be our second one and that is going to be the response object as well but we actually have to do a few things to this or excuse me this is not on the response object it is what we just set right here so we need to pass in expires and then we need to do a few things to it so first we need to get the value of this so this is just a javascript method that's going to take the primitive value of a string object and then we will say json.stringify and pass in that value so nothing too special going on here it's literally just to get us in the correct format and that's pretty much it for the set local storage method so we'll receive this object when we log in or register and then angular is going to take that object pass it into set local storage we'll see where this is actually used a little bit later but it's going to take that response object and set these two items in local storage now to log out we're just going to remove those two items so we can say localstorage.remove item and we just pass in the name of the item that we want to remove so once we remove these items from local storage when angular checks to see whether they exist it won't find them and it will make the user log in again so that's kind of what is going on here the next thing that we're going to do is this get expiration method and that is because this method is going to be required to see if a user is logged in now if we issue a jwt to a user then that means from um that the express application has already done all of the crypto cryptographic logic to decide whether the user is actually valid so if the angular application receives this response then we know that they are pretty much logged in so all we have to do is check whether the jwt is expired and if it is expired we need to delete it from local storage otherwise we can consider this user to be logged in so to grab that expires from the local storage we're just going to paste in a few lines here so first we're going to get the item it's not expires at it should be expires as we set it up here and then we're going to figure out um the so json parse is going to take the json our object and make it a javascript object this last return value is just going to calculate using the moment library it's going to just calculate the point in time which this jwt actually expires and then we'll come up in the is logged in route or not route but function and we're going to take this value the expiration value and see if the current time is before or after it to do that we just say return moment dot is before this is just a method that we have available to us and then we're going to pass in this dot get expiration which will return us the moment that this jwt expires and if it returns true then that means that the jwt is still valid and we should still be logged in then the last method here is just going to return the opposite of this dot is logged in pretty simple now that we've implemented this off service let's go ahead and see it in action before we do that i want to remind you what is happening when we register a user using the register component when the user presses submit on the register form this post request is going to be sent out to our express application which is running over here which will return that big object that we were talking about and looked at and then once we receive that response object we're going to pass it into the set local storage method which will set our token and expires properties in local storage let's test this out go to google chrome right now if i refresh the page you'll see that in the application we don't have anything in local storage for this application now let's go to the register route and let's put in something like jwt test and then a password of one two three and when we click register we should be redirected to the login route and you'll see that these two the token and the expires has been set to the local storage we also will console log the user object that we got back from the express server just to see that it was successful at this point we actually don't even need to log in necessarily because we've got these things set in the local storage but why don't we just go and do it jwt test one two three and then we're going to be redirected to the protected route but it says you are not authorized to visit this route no data is displayed and the reason being is because we have not yet implemented our interceptor which is going to take the jwt that is sitting right here in local storage and append it to every http request that we make in our express applica or our angular application in other words we need to find a way to when we click visit protected route while there is a token that is valid in local storage to get it to actually work looking at the protected component you can see that what this is doing when we click visit that route so ng on init so when this component is loaded the first thing that it will do is make a get request to this link right here which on our express application as you saw in the last video is only going to allow users to receive the correct data if they are authenticated with a jwt that the express server deems as valid right here is the protected route and if we are not authenticating correctly if our if we don't have a jwt attached to this get request or the jwt is invalid we should receive a 401 unauthorized error if we are valid then we should receive this message right here so here's the message you are authorized okay so let's close this out go back to the protected component and you'll see that if we get a response we're going to print the message attached that response so we should see what we were just looking at in the express application if it was successful but if we have an error which is going to be a status of 401 or unauthorized the message is going to be you are not authorized to visit this route and we saw that earlier in the browser so let's go solve the last piece of the puzzle open up the auth interceptor which right now is empty i'm going to paste in the implementation here and then we're going to walk through it so let me indent this correctly okay so again this is not an angular tutorial you're going to have to read up on interceptors which you can find on their documentation it gives you a lot of examples but basically what this is doing is kind of intercepting every http request that angular is sending out and it's going to attach or it's going to run the intercept method so what we're doing here is first we're grabbing this should not be id token should be just token we're grabbing the token from local storage and then if there is an id token so if we get a token from local storage then so far we're good what we're going to do is clone the request so we're taking the current request that is going through the chain of interceptors it's kind of like middleware and express almost and we're going to take that and clone it but this time we're going to set the authorization header equal to the id token so that should set authorate authorization header equal to bearer and then a space and then the jwt then we say return next dot handle and pass in that cloned object so that should basically right here that should successfully attach the jwt if we don't find a token which is very possible if the user is not logged in then we just return next.handle the request and there's going to be no authorization header whatsoever we now have an auth interceptor which should attach this jwt token to our request now if we go to the browser to our application technically if we visit this protected route right now it should say that we are authorized because you remember we already logged in and you'll see that we have the token and the expires already in the browser so as long as we attach this to our next request it should authenticate us so let's try that if you remember from the last request there was no author authorization header but now if we visit the protected route it says you are authorized and if we go to the network tab this is a little bit tricky you're probably tempted to click on localhost but we need to click on protected and you'll see that down in the request headers there is this authorization header which has the jwt that we had stored in local storage so that is the basic flow and you can use this concept to basically manage your users within an angular application and obviously there could be users with different types of permissions and that would require you to come back to your interceptor and write in some custom logic to say okay hey based on what role this user has are we going to attach you know the jwt or not and also you might be you might have routes on the express application that may or may not require authentication but hopefully this implementation so the combination of this auth interceptor and the off service hopefully those two things along with the previous video where we talked about how do we actually issue that jwt have brought your understanding of user authentication um you know to a conclusion and hopefully this all makes sense this is just one way that we can implement user authentication in our front end or angular app you're going to see a lot of different implementations across a lot of different coding languages the most important thing is to understand how everything works how does the jwt work and how are we supposed to kind of pass it from the front end to the back end once you understand that it should be a breeze to implement your own authentication strategy you never thought that we'd make it to this point but we're here we're at the end of this super long user authentication crash course and i want to say a big thank you if you watched all the way through that's really an accomplishment to get through you know however many hours this took us to understand all these concepts and if you are one of those crazy people that went from the very beginning of this uh course all the way to the end here and didn't skip anything i'd love to hear from you i'm on twitter at zg underscore dev and i'd really love to hear from you so reach out tell me what you thought about this course or just say hi once again i'd really appreciate if you checked out my much smaller youtube channel and just gave it a look and until next time i will see you laterwelcome to my complete beginners course on user authentication in web apps in this course we're going to be talking about how do you actually write that register form or the login form for your users using node.js express and passport.js and then later in the course we'll actually go into how do we apply these strategies to an angular application and then even further how do we write our own custom jwt authentication option but before we get into that i want to just introduce myself i'm zach and i'm a full stack developer i've got a smaller youtube channel where i cover a lot of these topics and i've been writing code for about four and a half years pretty much every day at this point and i'm super excited to share this particular series because it was one of the biggest struggles that i had when i was first learning to code i struggled with it for two main reasons number one i was scared of it i was scared to write a user authentication option because you know everyone talks about you know infosec and trying to secure your web apps as strongly as possible and how there's always you know loopholes and bugs and you know exploits and stuff like that and so this whole user authentication topic was very intimidating to me the second reason that it was really tough for me is because everyone made it look so easy i would watch tutorials where we'd get through the user authentication section in about 10 minutes and i was left just scratching my head because i had no idea what had just happened i had copied the code in the tutorial but i had no idea what was going on behind the scenes in this tutorial i want to solve both of those problems so with the security side of things this all gets easier when you realize that you know when you're first building your apps the the prototype version it's not important to you know secure your app on a grand scale like a corporation would have to the methods i'm going to teach within this course are perfect for someone who's just trying to get a basic auth strategy implemented and put it into their you know prototype app or even a small scale business it's going to be secure enough for something like that and on the second point in terms of understanding what's going on behind the scenes i really hope that this tutorial is the most in-depth user authentication tutorial that you have ever seen as you can see by the length of this video it is very long and the reason being is not because it takes us you know this many hours to implement authentication but because it takes us this many hours to understand all of the different components that go into an authentication scheme for example if we're using passport js we have to understand middlewares in express because passport.js is a middleware and not only that but it's actually a little bit more complex middleware than you're probably using on a normal basis on the actual authentication side of things there's a ton of topics that we don't really you know associate with user authentication when we're just trying to implement it for example do we understand cookies in the browser do we understand http headers that allow us to set those cookies do you understand how a json web token works what's in the payload of that json web token and furthermore in the payload of that json web token we're using techniques like hashing algorithms and cryptography these are not simple topics there are universities that have entire curriculums on just cryptography and concepts associated with it so as you can imagine talking through all of these things is going to take some time but i can assure you i'm going to walk you from point a to point b and i'm not going to leave you hanging on any part of this tutorial i genuinely hope that you enjoy it as much as i enjoyed making it and at this point i think we're ready to jump in today we're going to be talking about how you can implement user authentication in your web applications using node.js express.js and passport.js and we're first going to kind of jump into what are your authentication options in general i know that's a question that i had for a long time you know what do we have i hear stuff about jwt username and password and then you've got all this other stuff like oauth and even some custom strategies that you can use to authenticate your users so we'll go through that then we'll talk a little bit about the passport js framework what it is what kind of structure does it use to authenticate users into the apps and then what are some of the different strategies that you can use within it and then finally we'll actually go into the implementation of the passport local strategy in the passport jwt strategy although we'll talk about which strategies we might use in different situations both of these strategies are going to be really good for anyone who is just trying to get their app off the ground and their primary focus is not necessarily on authentication but they actually need authentication to get it off the ground so these are kind of like the the bare bones um most basic way to authenticate users into an application and it's going to be great for you know individuals small teams startups anyone that is building their application from scratch there are a few prerequisites for this tutorial series i've pretty much assumed that you already know the basics of coding within the node.js ecosystem so that means you know you have a pretty good understanding of node.js modules and package.jsons all of that kind of stuff as well as things like the express framework also things like asynchronous programming so promises and callbacks hopefully you're at least a little bit familiar with all of the topics here on the screen if not you can still get through the tutorial but i would highly suggest kind of brushing up on anything that you're not you don't have a very basic understanding of the first thing that i want to cover is what are your authentication options here before we get into any coding it's pretty important to take a look at what's available to us and deciding what is my use case and what's going to be best for that use case so on the screen i've laid out all of the authentication options that you might find if you are in the node.js ecosystem or any other ecosystem for that matter and they are listed from least complex to most complex but that does not mean that the least complex option is the worst option it just means that as you kind of move up that chain it's going to require a little bit more understanding more pieces that you have to understand to implement the strategy itself in the scope of this tutorial series we're just going to be sticking with the left two so the session based authentication aka the passport local strategy and the json web token or jwt authentication or aka the passport jwt strategy now you also have a little bit more complex authentication that you'll see especially if you're trying to use um a large api like maybe the youtube api or any google api um even github's api these big companies rely on oauth it's just a protocol to give different access rights to users trying to access resources within their api so you'll kind of get the gist of what that is as we get into the jwt authentication but i'm going to stay away from completely diving into the oauth although we're not going to actually get into the the coding implementation of solutions like oauth or even custom solutions it's definitely important to at least touch on it so what oauth is all about it's it's just a protocol and i know that can get pretty confusing when you have um software as a service providers such as auth0 and octa among others that actually provide this oauth protocol as a service so you it's really confusing if you look at those companies you know namely one that's named off zero which sounds like a protocol it gets really jumbled in your head like what's the protocol what's the company you know how is all this working so really what oauth what the oauth protocol aims to do is separate out the two components of we'll call user authentication i got to be careful with the terminology here because there's a big difference between authorization and authentication so on the left with the jwts and the local logins the session based authentication that is all about knowing who the user is and that is what we would call authentication now on the other side of things if you have seen things like social logins like sign in with google or sign in with facebook that's a little bit more about authorization so that's kind of it's not as much who who we're talking about but instead who has access to what resources so in other words you'll get into things like scopes you know what does this particular subject or user have authorization to access does it have authorization to make just get requests against the api or does it also have authorization to edit certain resources within the api so as you might guess using the oauth protocol and you'll also hear things like open id connect is closely related that is going to be used with these bigger services where you know maybe one company such as google allows users that have varying authorizations to access the api in the same way so if i or you wanted to access resources from say google's youtube data api so if we wanted to get youtube analytics or something like that we don't have authorization to do certain things within that api and that is defined by the scopes that we are basically provided in our access token that's related to the oauth protocol now i know all that sounds very complex and it's definitely not something that you can even begin to understand completely in just a few minutes but i did want to talk about that um and kind of just mention what it is and why we're not going to get into all the details of it i think we have plenty on our plate with the session based authentication and the jwt based authentication to even start talking about that so those are your options we're going to stick with the two on the left the least complex ones and probably the most common implementations that you'll see for startups and people who are just trying to get their application off the ground and worry about the complex authentication of it a little bit later down the road when they have either more resources more money or both that can actually spend the time to implement something a little bit more complex like the oauth protocol to wrap up this introductory video i wanted to give a brief overview of what the passport.js framework is and the reason being is we're actually going to be implementing two different strategies within the passport framework but that just basically means that we have two different middlewares that are connecting into the bigger passport js middleware so you might ask what is a middleware for those that are not familiar what middlewares are in express or are just a little bit fuzzy on how they work i have created a video that will be included in this playlist so that you can brush up on that and get yourself up to speed but basically all that passport js is is a middleware that integrates within your express.js application and handles all of the authentication logic using the specific strategy that you choose to plug into the passport.js framework now the strategies that are included if we go to passport js we can go to the home page and see that there are plenty of different strategies here so we can do anything from the passport local and passport jwt like we're doing and we can also do something a lot more complex you can see that we have stuff like the passport oauth 2 which is what we just talked about or even you know something more specific passport instagram we can use the instagram login to authenticate our and delegate access to our users so there's a lot of different strategies and all of these strategies have been created by independent developers that basically say okay here's the passport.js framework it's just a middleware and it allows me to kind of use that framework as a starting point and then we can just build in the the specific pieces of authentication in our own middleware which we call a strategy so in summary passport js is just a framework that is a middleware that also allows individual developers to develop other middlewares called strategies that connect in with this bigger middleware that we call the passport.js framework and then all of that gets wrapped up into a bundle and put into your express app and it works seamlessly with your express routes we'll see in a lot more detail how each of these strategies the local and jwt strategy work as we go through the series but it is important to just understand the basics of what this is if i had to sum up the code logic of passport.js in a few sentences it would basically be this so passport.js is a middleware as we just talked about and on every http request that a user calls to our express server the passport framework is going to first pick up okay what strategy are we using here and then it will use that strategy to say hey is that user that just requested that resource authenticated if that user is authenticated then passport is going to let that user access the resource it's going to you know go into the express route if that user is not authenticated based on the strategy we're using then passport is going to return a 401 http status which is basically the unauthorized status so that's kind of passport.js in a nutshell again it's going to get a lot easier as we see the actual code flow of what's going on with this middleware congratulations you made it through the first part of this super long tutorial on user authentication now we talked about all the different options here and we're not going to be covering some of those delegated authentication options but there's plenty to cover with the other ones and particularly with the passport local authentication strategy where we're going to be using the express session middleware having a solid understanding of http headers and http cookies is going to be absolutely essential as a web developer you go on a bunch of different sites and you click that accept button when they say you know we use cookies on this website but you actually know what that means i think you're going to find this section interesting but let's go ahead and dive in what is an http header i think it's something that we know in the back of our heads kind of what it is especially if we program a lot of web apps but it's also something that we don't spend a lot of time trying to learn and we frankly don't need to learn a whole lot about them that said we do need to specifically learn about an http header called the set cookie and the cookie header in order to understand how server-side sessions work and kind of interact with the browser so if we come to google.com right here i always use this as an example just because it's pretty arbitrary spot if you open up your developer console here in google chrome and go to the network tab you'll see that it is pretty much empty right now but if we click refresh on the google search and we're basically doing a get request to google.com and you'll see a bunch of stuff loading a lot of these are the resources that run the page or scripts but at the top you see this www.google.com if we click on this you'll see that there are some headers here and you'll see that the headers come in three basic categories first you have the general headers then you have the response headers and finally the request headers what we're specifically interested in in this case to understand what a cookie is and how it works is the request and the response headers but we can also kind of explore the rest you can go on to mdn is a great place to look and you can see there's you know a link to all sorts of different headers so we can go down here into security and these are all the different security headers that you could set in either the general response or request headers now let's take a step back and really think about what just happened when we pressed the refresh button in our browser to load google.com if you think about it a http client could be anything from an iot device someone like me sitting at my desk or at a coffee shop you could think of it as just a laptop or a phone pretty much anything that connects to the internet is considered an http client now on the other side of things is all of the http servers and those servers google in this case is going to house the information that the clients want to access or update or do other operations on so in our case what we did was do a get request to google.com in other words we want the resources at that web page so if you look at the headers here in the chrome tools you'll see as we talked about we have these three categories so let's just go ahead and walk through each of them and see what was relevant to our request so in the the first one the general headers these can be either request or response related they're just kind of general metadata about the request such as what is the url that we're requesting what type of method are we using so this is a get request those were both probably those are in the request side of things now if we go to the response side of things you'll see that we got a status code of 200 which means that we requested data from google and it sent back the data successfully so you can see that we have several you know things that kind of mix between the request and response now in our particular situation when we searched google we formed or we didn't form but the browser that we were using created a request header which is basically instructions for the server in what data you know the request wants so i'm the client here sitting at my computer so the the browser on my behalf is going to say hey whoever i'm trying to get these resources from i'm going to put in the request headers what kind of data i accept so you can see that we have things like the accept encoding except language and then just the accept http header and we're basically saying that we accept html we accept xml and a couple other different options but you can just think of this request header as the instructions for the server that you're requesting resources from or trying to modify what type of data that the client myself will accept in the browser is not the only thing that you can put in this request header you can put all sorts of other things you see there's a cookie in here we'll talk about that in a few minutes but you also have things like the user agent tells us what browser is requesting this data and then if again you can go to the mdn site and look at a broad variety of different things that you could put in the request header so you can click on the request context and you can kind of see some of the things that you can put in that so we know that http headers are basically metadata about our our http request so we can also do that on the response which would be set by the server which in this case is google so one of google's servers whichever gave us the content that we're viewing on the web right now is going to set these response headers and these response headers are going to give additional instructions to the client that requested the data in the first place so you can go through a couple of these and see you can see the content type so if you remember in the request header our you know the client which is the browser i'm sitting in and using right now said i only accept a certain type of data and then the response is going to say okay you only accept that type of data here's the data and here is what type it is so this is useful if you know we're trying to figure out how to display that data in the browser of course there are other things that that you'll see here but i want to direct your attention to something very relevant to what we're talking about right now which is the set cookie header now you can see that the set cookie header is basically giving key value pairs and you can see you know right here it says expires equals friday the 31st of january 2020 at this specific time so you might be asking well there's a cookie header in the request object and there was a cookie header in the response object how can that be what is the difference between the two and how do they work over the next few minutes i'm going to walk you through exactly how the set cookie and the cookie headers kind of work together and then in another video we'll actually talk about how this all plays into what we call a server-side session the easiest way to understand what a cookie is and how it works is to remember that http protocol is a stateless protocol in other words it's going to constantly forget what the user has done on the site unless we have a way to remember that so in other words if we go to google let's just imagine the scenario we go to google and we sign in to google and we'll just assume they actually probably don't use this method but we'll just assume that they're using cookies and server side sessions to authenticate us so what happens is google the server is going to say okay the client that just you know signed in gave us valid credentials and so what we want to do is you know send something back that allows the browser to remember that this user has logged in if we don't have anything like cookies or local storage probably more modern way to do it if we don't have these types of persistent storage then every time we refresh the page our the state that we had previously where google said okay we logged you in is going to have to be redone so every time you refresh the page you're going to have to enter your login credentials which of course is a terrible user experience and any site that does that is going to lose their users immediately because they're going to get completely tired of typing in their login credentials so this is where the set cookie and cookie headers come in so let's do a little experiment here and i know this is not a perfect example but i think it will do for what we're trying to accomplish here so let's click on the application and open up cookies for google you'll see that there's all sorts of cookies you know google knows everything about everyone so we can just go ahead and delete these it doesn't hurt anything to delete all these cookies so at the moment our browser has no cookie set whatsoever so we can come back to the network tab and let's go ahead and refresh the page once more you'll see that we had this google.com here and we can open up the response and request headers and you'll see that the request headers it's pretty much the same as what we had looked at before and then in the response headers we once again have these set cookie headers and what these are doing is basically saying okay or the the google server is saying okay client i want to set this information about you so we'll just assume maybe we just logged in and google wants to tell the browser that i the client is logged in and we don't need to re-authenticate every single time that we've refreshed the page so what happens here is we have these set cookie headers and let's just pick a very specific key value pair here just to see what's actually happening so let's get a pretty easy one we'll just say the 1p jar it gives us a date of 2020 1-21 i'm not exactly sure what that means but keep this in mind this is what we're going to be looking for so if you go to the application you'll see that now these are set in the cookies field so we have the 1p jar and then the value that was set in this response header so now what our browser will do is it says okay now we have a cookie set so every request that we make within this domain so google.com i want to attach those cookies that were set based on this set cookie http header in the response header so what's going to happen is when we press refresh again it's going to actually put these cookies in the request headers so right here in this cookie request header we should see something like these set cookies that google the server had put into our browser so let's click refresh once more go to thegoogle.com and look at the request headers and you can see that now this cookie header right here has that 1p underscore jar cookie key value pair so just to recap what just happened we had a client me refreshing or doing a get request against google.com and whatever google server that gave me that data said i want to set a cookie in this client's browser so it uses the response header to do that it assigns these values in the set cookie header and then when we reload the page our google chrome browser or any browser for that matter is going to say okay my default behavior is this is to look up what cookies are currently set in my browser and i'm going to attach those cookies to every single request for the domain context that it is applicable to which is google.com in this matter if you really think about it this method of setting and then the browser just attaching the cookie to each request is a really powerful thing when it comes to user authentication you could say hey maybe my server can do some sort of logic and say okay is that user valid invalid did they give me the right password if they authenticated correctly then i do the set cookie header in the response object and then now the user or the client that is using my web application now has that cookie that says yes this user has already been authenticated and then the browser every time it reloads will attach that cookie and you don't have to re-log in that user now the real question is how long do we keep that user logged in and that's a totally arbitrary question but we can do that with the expires piece of this set cookie http header if we come over to the network tab and look at the response headers from google you'll see that there's the cookie that's being set so 1p jar it looks like this is actually set on every get request to google but you'll notice that it has an expires piece to it so this is what tells the browser how long to store that cookie key value pair within the the client so we can actually go through this exercise on our own using some simple javascript to see exactly how it's working so let's go to the console and type in a few quick commands so first we're going to create a new date which is going to represent the date and time right when i click enter so we'll say enter and then we're going to say we want to set the time 20 seconds later so let's do that and then finally let's set a cookie to the browser with the an expires header at that time so we really only have a few seconds but you can see that we have a custom cookie that's going to be there for about 20 seconds so if we reload right now it shows that it's gone so let's go ahead and do that one more time a little bit quicker this time so here's our cookie go over to application you'll see that we have the custom cookie and every time we refresh the browser you're going to see that cookie is going to stay there but then in about 20 seconds which is coming up here in a few seconds i think you'll see that that cookie actually will drop off and it will no longer be attached to the http request so if we refresh you'll see it's gone and that user will say that that was a cookie that gave a user or the client's authentication status that's gone the user has to re-login now obviously you're not going to set a cookie to last for 20 seconds you might more realistically say that you want the cookie to last for two weeks and that is a really powerful way to keep some sort of persistent state within the browser and not require users to log in every time they refresh the page the next part of this tutorial is all about express middleware in order for us to implement the passport local strategy which utilizes express session we're going to have to understand middleware and that's because both passport.js and express session are both middlewares if you don't understand this concept really well then both of those libraries are going to be confusing to you furthermore i'd consider this one of the most essential topics of programming in the express framework while the official express documentation does cover express middlewares in some capacity and it's relatively clear when i was a beginner i'd never understood it fully and even to the point you know two years into my programming journey i still did not have a solid grasp on this express middleware after learning it in depth for the first time i can really confidently say that this is going to be one of the most important lessons that you learn you know as a node.js developer using that express framework so without further ado let's dive into this express middleware overview when you start out using express.js as a framework it's an entirely middleware based framework but generally when you first learn it you're just copying in you know the different pieces and you know that there's kind of something working behind the scenes but you don't know exactly how it's working so in this video we're going to talk about how exactly does this middleware work and how does the request response and next or callback object as well as even the air object work in express application in order to do this we need to spin up a really quick basic application um what i'm working in here again this is part of the passport.js series so i'm in the repository that we're using for that but don't worry this is just a basic express app so we first need to require in express i've already installed this with npm so i don't need to do that and then we say app equals express and then we just say app.listen on port 3000 so right there is the most basic form of an express server that you can spin up and if we were to visit localhost 3000 we're not going to get anything but if we just throw in one simple route app.get and then we pass in the request response and next objects and then we send some sort of data we can now run this in the browser so let's use nodemon which is going to automatically update on every time i save and we'll run app.js so we're running app.js it's listening on port 3000 and it'll be listening on localhost so if we go to the browser and visit localhost 3000 port 3000 you should see the hello world so we have a basic server running and that's all we need to do to start understanding how middleware works in express so we come back to the code here and the first thing that you need to understand is this right here so with our app.get this is just a route that we've established in our express application we are passing in a route string and a callback function usually you'll see it in this syntax but to better understand it we can just basically write a function where we say request response and next now to make this even more transparent what i'm going to do is name these custom properties so normally you're going to just see it r r e q r e s for request and response and then next but you don't need to call them that it's just always going to be passed in you can call them whatever you want so we can say request object response object and callback function so well actually we probably shouldn't call it the callback function we should say maybe next middleware or something like that because the purpose of this last parameter is if we call it as a function it will pass it to the next middleware in the chain so we'll understand that a little bit better in a second but first let's go ahead and write our function so we need to give it a function name so we'll just say standard express callback and we pass in these three parameters and then we can say res.send and hello world so basically we've got the same exact thing that we had below in the app.git route to implement this let's just delete what we wrote here and let's just pass in our standard express callback so we've defined it up here we know that express as a framework is going to pass in these three parameters and so there we can just throw it into our route and click save and then if we come to the browser again if we refresh the page it's going to say res is not defined and the reason being is because i was dumb and forgot to update that so now that we're passing in request and response object we obviously need to also use that in the body of the function so that was just a silly mistake but now if we come to the browser and do it again we should get hello world as we expected so that's the most basic way that an express route works and we're using this function that we had defined so just like we could define this function we can also define other functions which we call middleware so the way that we do that is pretty simple we'll just say middleware one and what we need to do is pass in those same three objects that we were using before so the request object response object in next middleware or whatever you want to call them in this case i'll just say record req res and next like you would normally see it and then we can do whatever we want in this middleware so maybe we'll just say console.log i am a middleware and then in this one this is the standard express callback this is where we return some data we can say console.log i am the standard express function so if we just define that function up here and we don't do anything with it it's not going to do anything obviously but we can pass that into our route to make it work for us so let's pass in the middleware one and a comma so you can see that express as a framework allows you to pass in pretty much as many parameters to the different route functions as you want let's go ahead and save this real quick um let me open up the terminal a little bit more so that we can see what's going on and let's go to the browser and visit that same route we'll go ahead and click refresh here and you're gonna see that this is gonna just keep loading it's not gonna ever return us data and if we were to you know copy this into a new tab and click enter it's not gonna actually return us anything and that brings up a very good point with express middleware if we come back to our code that we wrote you'll notice that in this middleware that we passed into our route that we were visiting we haven't actually called this next parameter so in the express framework the next parameter is going to be actually a function and all we have to do is call it at the bottom of our middleware and what that's going to do is it's going to say for this route right here we first run middleware middleware number one or middleware one and in middleware one we call the next function that was passed in as a parameter by default by express and when we call that it's going to basically say okay now we get to go to the next middleware or in this case it's the last one it's the standard express callback so if we don't put that next function and call it it's never going to get to this last function and we're not going to ever return any data so now that we've called this next function we should be able to go back to the browser and see a response so if we refresh we'll see that it should return hello world and you see that it did return it and if we come back to our code again you'll see in the console that we printed i actually ran this route twice so we printed i am a middleware and then i am the standard express function and the order of this is very important because first in the route we run this middleware and then we run the standard express callback so first we're going to console.log i am a middleware second we're going to console.log i am an express function so that is the basics of how this middleware works but we also have a few other things to understand so what we've been using so far by passing the middleware into the route itself is a route specific middleware now this is kind of i just think of it this way i don't know if it's the exact term that you would use but i call this a route specific middleware but you also can have global middleware so if i took this out of the route and i came up to the top right under the definition for the app and i say app.use what this function built into express expects is a function or a middleware that it can execute so in this case i'm going to just take middleware number one or middleware one and say app.use middleware1 so what's going to happen is the express app is going to initialize and then it's going to initialize the middleware one so let's go ahead and see what happens in the console when we do this so i'll let me make sure i got this right so we've got our middleware defined here we call next and we're initializing it with the app.use up here so let's save that and you'll see that nothing has happened in the console yet you might expect since we did this outside of a route that it would just automatically print i am a middleware and go to the next something but that's not the case when we say app.use it's basically just adding a piece to that chain of functions or middlewares that we're going to be calling so once again we have to come back to google chrome and execute this git route so let's enter and so it loads correctly and then if we come back to the code again now you're going to see i am a middleware and i am the standard express function so what just happened here well first off we defined that this is the first middleware that we want to use in all of our routes it's not just specific to this particular route it's going to happen in any route that we define within our application next we have the standard express callback which is in this specific route so first the route's going to call middleware 1 then it's going to com call whatever we had defined as the callback to that route so the order of the middleware that we define in the scope whether it's a global or a route specific middleware really matters so let's go ahead and see what happens if we switch up the order of the middleware and maybe even add another middleware into this equation so let's say we have another middleware called middleware 2 and again we pass in the default objects that we are provided by or provided with by the express framework and we'll say console.log i am middleware number two and maybe we should just update this one up here to number one so we've got middleware number one and middleware number two and what i'm going to do is say app.use middleware to okay so we are using two middlewares and then we have the standard express callback which at this point i'm just going to go ahead and put it in a form that we're used to seeing so we'll just use request res and next this is what you'll see in most tutorials so i want to keep it consistent so let's copy that in there delete the function declaration and then of course since we changed the name of the parameter we need to also change the name of the object that we're using to send the data all right so let's just quickly recap what we got we have one route in our application which has a very standard syntax all we're doing is we're sending back an h1 tag with hello world in it so far in this route we haven't defined any route specific middleware but we have defined global middleware so let's see what happens go ahead and kind of make your guess as to what's going to happen here but if i had to guess we're probably going to print i middleware number one and then i am middleware number two when we call that route and then finally we'll you know console.log i am the standard express function all right so we've saved it let's go back to the browser click refresh and i don't know why it hangs sometimes here try it again maybe we have some sort of air did a little bit of refactoring nope it was doing just fine we've got all the things that we expected so if you could guess what's actually happening here is again we forgot to call the next function in the middleware 2 so it never reached this final function save it once more come to the browser once more and refresh we should get a good response come back to the code and you'll see i am middleware number one i am middleware number two and i am the standard express function all right so everything is as expected and now is where the real you know understanding comes into play because oftentimes when we're using an express application we've got all sorts of middleware working together in most express applications you're going to have several app.use statements so you might say app.use course cross-origin resource sharing that's a pretty common one or app.use body parser and then whatever the configuration for that was so you might have up to like 10 15 even 20 different middlewares that you are adding to your express application and so it's really important to understand that the order that we put these in matters so if we were to put middleware 1 after middleware 2 all we did was change the order of those statements if we save and then go to the browser and call that route you're going to notice that when we come back to the code we now have things out of order so we have i am middleware number two coming before number one so that's really important to understand and then of course if you put one of these within the route itself it affects the order as well so let's add one more middleware to this equation and it's just let's just copy this do the same thing so we'll call this one number three number three right there and then we're gonna take middleware number three and put it in the route itself so let's copy it right there give it a comma and now what's going to happen is we should have middleware 2 called first then middleware 1 then it goes into the route specific middleware so then we have middleware three and then finally this last function which we technically could call middleware as well so let's see if that worked we should have middleware two one then three so let's go to the browser run the route come back to our code and you see that we have two one and three exactly how we defined it two 1 and then the route specific middleware there are two more things that i want to talk about when covering the topic of express middleware and one of those is air handling because an air handler in express is also just another middleware but it's actually a special type of middleware so in order to define an air handling middleware what we have to do is define a function with a fourth parameter so let's go ahead and define a function called air handler and you'll see that in this app i've kind of simplified it a little bit so we only have one middleware we got rid of all the rest of the stuff but this time we're going to pass in an error parameter then the request res and next parameters so this is how we define an error handling function and we can you know this is basically a middleware so we can do as many error handlers as we want so if we wanted to catch specific types of errors so we say if air dot status equals something then we want to you know handle it in this one and then we could come down and do another error handler and say this is error handler number two and if error air dot status is number two number one you kind of get the point we can define as many of these as we want and handle different types of errors depending on the application that we're doing but what is going to happen here is this error parameter will be populated with an error if it exists so what we can do is we can say something like maybe instead of throwing the air explicitly we'll say if there's an error what we can do is res.send and we can say there was an error please try again so something more friendly than a default error that you would you might get in the browser that would crash the entire application so let's go ahead and comment this out for one second and see what happens if we don't have an air handler so right now we don't have an air handler and maybe in this middleware up here instead of console logging i'm a middleware and continuing to the next we can say that we have an air object which is a new node.js air so i am an air and what we can do with this is we can pass it in the next function so normally we just call next and it goes to the next middleware this case we're going to actually pass the air object so this would be common you know this would be more common in a scenario where maybe our middleware was doing something complex we were making a database call and we were just catching any errors that happened with the database something that we cannot control so we always want to catch these errors and if we do catch them we want to pass them in the next function so when we do that we're going to go back to the browser real quick and if we refresh this it's going to say i am an heir and you're going to get the entire stack trace which you don't want because this is where the users will see what's going on and you obviously don't want to send this type of error to a user you want to handle it in a more graceful way and not to mention if we do it like this you can see down in the console or in the terminal that we've crashed our application so if this is running out on a server somewhere and we don't know that this has happened our application could be down for hours without us even knowing so it's really really important that we use an error handler in our express application to catch these errors and handle them gracefully without crashing the express application so again air handler just another middleware with one extra parameter so let's uncomment this air handler function and normally you'd set this up a little bit more complex than what i've done but we'll just go with this for now just to demonstrate the point so we've got the error handler and so now we're going to say app.use air handler now we'll go to the browser again we'll refresh and now we're getting a more friendly error message now that we've defined this error handler let's go ahead and put it in as a middleware so let's just say app.use air handler and click save now let's come back to the browser real quick and refresh you're going to see this dreaded error message in the browser you're going to ask yourself why we defined our air handling middleware so we should have a friendly message here well what's happening is we have done this out of order and like i said earlier in this video the order that you put express middleware in matters and in this case we need to throw our air handler at the very end of our app so after all of our routes and all of our middleware we need to put our air handler and the reason being is because if there is an air in any of our middlewares or our routes which are basically just middlewares then the air is going to be passed directly to the final air handler so in this case we have the air happening up in our first middleware so what's going to happen when we say next and then air express is going to pick up on this and say oh there's an error let's send it past you know let's skip the route here we don't need to go into this we need to just go straight to the air handler and handle it appropriately so this is kind of how express middleware works and you can see that this will more gracefully handle the air if we come back to the browser and refresh now we're getting a much used more user-friendly message in many cases you might do something instead of actually sending data like this we could just say res.json and then we could say air and then our front end application could handle this error on the front end rather than you know the server handling it alright so we have covered how to handle errors using air handling middleware and finally the last thing that i think is important to cover when it comes to express middleware is the fact that we can actually mutate or kind of append different properties and objects and functions to these parameters that we're passing through each of the middlewares so what we could do here is let's once again let's get rid of the error in this middleware let's also get rid of the console.log we just want to have a basic middleware let's call this number one again then let's say number two and let's put these in as global middlewares so here's middleware one and two so first our route's going to call middleware one then two and then the actual callback for the route so to demonstrate this let's go ahead come up to middleware one and say something like request dot custom property equals 100. all right so we just created a variable that is attached to the request object now since we're passing since express as a framework passes this request and response object through each of the middlewares it will actually be available to us in later middlewares so what we can do is we can say we define it up in middleware 1 then in middleware 2 we say console.log the custom property value is and then let's put in that custom property so in middleware number two we should print the custom property value is 100 but then we want to reassign it so let's say custom property equals 600 just a random number and then finally down in our routes we'll say the value is and then we'll put in request dot custom property and in this case it's probably going to print or not probably it will print 600 because we have modified the property in middleware number two so let's save that go to the browser and see what we get so we see we see that the value is 600 and that is because we set it in our second middleware which was the last middleware that modified that property now you might be asking what is the point of this why did you show me that well the reason being is because it helps you to understand how a lot of the middlewares that we use on a daily basis in express are actually working so if you're following along this series the passport.js series for user authentication this is exactly how passport js which is in express middleware is going to keep track of users whether they're authenticated or not they the passport middleware is going to take that request object and it's going to actually append different properties to it and also if you watched the previous video in this series on the express sessions middleware you also know that the request.session object is where the session is stored so you can see how powerful this is and how we can actually store data within the request object and you know each of our middlewares can have access to that data even if they come way after the middleware that first modified the data so that's just kind of a brief explainer of how middleware works in express and how air handling middleware works in express hopefully it kind of um broadens your express horizons a little bit i know when i first learned it it did um and it made me a lot better express developer i now write middleware for all of my applications to do just ad hoc things anywhere from you know authentication guards so maybe we're checking a value of a user that we've received maybe we're checking if they have administrative rights and we use a middleware to do that so the middleware would basically look up the user in the database check the admin property if the admin property is true then we pass it to the next middleware if it's false then we might return something like 401 or 403 unauthorized http statuses all right after this last section on express middleware we are now set up to really understand the express session library when you're implementing the passport local strategy it uses express session under the hood which can be extremely confusing and when you read through the passport documentation it doesn't make it abundantly clear that this is happening in this section i'm going to teach you exactly how this express session middleware is working behind the scenes kind of independent of the passport js middleware itself and then we're going to talk a little bit more about how that express session is being looped in to our passport authentication middleware now the really cool thing about this section is that learning the express session middleware is not only going to help you implement a passport local strategy but it can also be really useful for other purposes within your web app well state management is often handled on the front end with frameworks like angular vue.js or react there is the possibility of handling some sort of state or application state on the back end in the form of a session that is what the express session library aims to do but enough talk let's dive in and understand all about this library so in this case we're going to be looking at a very simple express app and i'm going to take you through how the session is working how the cookies kind of work with the session and some of the configuration that you have to do to set up the express session middleware what i've got open right now is the repository that goes along with this passport.js tutorial series and we just have a folder for little one-off tutorials like this one i've already created an application which is an express application and i'm just going to quickly walk you through what i've done and then we'll go through what's actually happening what are some of these configuration options so the first thing that i've done i've already installed my dependencies we've got express mongoose for the database and then express session which is an npm module we then have something called connect which we'll get to in a few minutes it's what we're going to actually use for the session store then of course we set up our express app pretty familiar to most people we connect to our database right here so i'm just using a completely unauthenticated localhost database i've got that running in the background already so if you're trying to follow along be sure that you get the mongodb server or that process running before you try to run this app so we're just going to use the tutorial database and then these options here are just set because when you run the application is going to complain about it if you don't put these so that is all we've got and we create the connection right here so the connection represents um our database connection and then down here we have some pretty familiar json and url encoded middleware which is going to allow the express server to parse the different request types so that just pertains to the type of responses that we're getting in on the server and then finally we have things related to the session itself which we're going to dive in a little bit deeper and at the bottom we've just got we're listening on localhost 3000 and we have one simple route for the home page just says hello world sessions so that is our app this is the only file we're working with and so it should be pretty straightforward like i said this tutorial is not an express tutorial and i assume that you already have a decent understanding of how the express framework works i'm trying to stick primarily to how the express session middleware works so if you don't understand how express works or how middleware works be sure to check out some of my other videos or just read some of the documentation online before we get into any of the configuration and understanding how the express session works we need to answer the question what is the difference between a session and a cookie you'll see that in the configuration i've got a cookie set and in a previous video that i did again link is in the description um we talked about what a cookie was so basically a session in a cookie are different in the places that their data is stored so a cookie has its data stored in the browser and that browser is going to attach that cookie key value pair to every http request that it does a session on the other hand is going to be stored on the server side so when i say server side just the express js application and so this express session is going to store a little bit bigger types of data so in a cookie you can't put a whole lot of data and it gets very tedious if we're constantly adding more and more data to the cookie that we're attaching to each request so it would make sense to put that in a server-side session where we can store much larger amounts of data in addition a server-side session is advantageous because with a cookie we cannot store any sort of user credentials or secret information if we did that then a hacker could easily get a hold of that information and steal personal data so the benefit of a session is basically the fact that we have it on our server side and we're actually authenticating into the session with a secret key so with that said that is the main difference between a cookie and a session i want you to keep that in mind as we're talking about the two in this video now that that's covered we have some time to get into the actual code and configuration of an express session and then i'm going to show you kind of how it works in real time so what we've got on the screen right now is the express session documentation it's just an npm module a pretty popular one at that and you can see on npmjs.com there's all the documentation that you would need to learn how to use this but i'll just point you towards a few of the common things that you'll see first off of course we require in the express session and then these options right here are what are going to be included in that options object so if you look at the code here you'll see that for our session we're saying app.use so that's just we want to use the session middleware and then we've passed into the session middleware an object right here which represents our options so if we go back to the documentation really quickly you'll see that all of these options are documented right here under the options section now the one thing that i wanted to point out you get through the options that's great fine but then you get to the bottom somewhere down here and it talks about a session store implementation so if you're unfamiliar with what that is it's basically deciding what um persistent memory are we going to store our sessions in if you remember from a few minutes ago i said that a session is used to store information about a particular user moving throughout the browser or a client and so we can potentially get up to a decent amount of information and therefore in a production environment it would be useful to have an actual database storing that information now by default the express session middleware just comes with its own implementation of a session store but it's not using a database it's just using in memory or memory that's local to your application and it's not going to be a scalable solution so what we need to do is set up an actual session store which is a fancy way of saying we need to connect our database to the express session middleware so there's going to be a lot of options for what session stores we can use and they're documented here at the bottom the one that we're using particularly is the connect session store which is probably one of the most popular ones and it allows us right here to connect to the mongodb database that we have running in our express app so let's go back to our app real quick and see what i mean so to do this session store to connect it up we first have to have our database connection so we talked about this a few minutes ago here's our connection we're just using a tutorial database on localhost nothing you know you'd obviously want to change this if you're in production but we've got this running on my computer and i can actually come down to the terminal here and run the shell and you'll see that we can show dbs and you'll see that we have a tutorial db set up when we connected to this database now what we want to do is we want to tell the express session middleware that we want to use that mongodb database for its session store so you'll see that that happens right here in the store option of the session middleware and so what we've done is we've passed in the session store object into this store option and the session store object is set up right here and it is basically just using that connect right here the connect package and we're configuring a few options we're saying that the connection equals the connection that we just set up and the collection that we'll be putting our sessions in is going to be called sessions pretty standard pretty standard option that we have here you can obviously customize it a little bit and if you went to the documentation of connect there's a few other options that you can set but what i want to show you is what is happening when we connect everything up so in my first terminal i will run this application so let me go to the path here and we're going to run the application so we are listening on localhost 3000 and if we come into the browser here i've got this queued up so that we currently have localhost 3000 ready to go but i have not clicked refresh yet the reason being is because i want to show you exactly what this middleware the session middleware is doing so let's first come back to our code and what we want to do is go to the shell and we want to use the tutorial database so now we've switched to the tutorial database let me clear the screen and we're going to show the collections that exist in that database when i ran the app it initialized this sessions collection in my database but if i say db.sessions.find there's going to only be a couple objects in here let me just go ahead and drop this really quick because i think i had some stuff from previously so let's just say db.sessions.drop so we dropped the database if we show the collections now there's nothing but if we were to come here and refresh the app so we're using nodemon so if we click save it's going to refresh the app we're going to go into show collections and you see again that the sessions have been established and if we say db.sessions.find we shouldn't find any documents whatsoever in this collection so we have a completely clean slate and in order to establish a new session all we have to do is make some sort of http request to our application so if i came to the browser and i clicked refresh here what's going to happen is that session middleware is going to kind of fire it's going to create a session and then what it's going to do is create a session id which is going to be stored in a cookie in this browser so like you know just like we don't have any sessions in the database yet we also don't have any cookies in the browser yet so let's go back to our code and what i'm going to do is just walk you through a few the options and then we'll finally see exactly how it's working so when we set up our session middleware we have a secret pretty self-explanatory but this secret is going to well usually it's going to be stored in an environment variable and you don't want to expose this to the public because it basically says if the secret is invalid then the session is invalid too but in this case i just put some secret just so that we can have it all in front of us then we have a couple options here resave and save uninitialized and these are just options relating to what does the session do if nothing has changed what does the session do you know if something has changed and basically tells the middleware how to react to different events in the browser you can read up on the documentation a little bit more on these options but the thing that we're interested in we already talked about the session store but what we're doing is we're setting a cookie max age so in other words like we talked about in a previous video a cookie can have an expires header and or not a header but an expires property which says after a certain amount of time the browser is going to delete the cookie and it's not going to attach to any of the requests in the future so in this case we're setting our cookie equal to one day and you can see the math that we're doing here in the comment we're basically just saying one day 24 hours in a day 60 minutes in an hour 60 seconds in a minute and a thousand milliseconds in a second and so that's the math that we're doing right here to get to a full day for that expires property so basically what's going to happen when i send an http get request to our sole route right here is the session middleware is going to initialize a session and then it's going to take that session id and set it equal to this or set the cookie equal to that session id the cookie is then going to be put in the set cookie header http header and then that is going to be in the response header it's going to go in the browser the browser is going to receive it and say oh you want me to set this cookie i'll set the cookie and now every time we refresh that cookie will be a part of that request so let's go ahead and do this we're going to visit our only route in the application and to do that we need to go to google chrome and we're going to click refresh so when we clicked well now we it did not load so let me go ahead and do that one more time we refreshed it we get our response it says hello world sessions and what you'll notice is now we have this cookie which is by default called connect dot sid in the express session middleware and we have some sort of value here which somehow corresponds to our session id so basically what's happening is the express session middleware is going to get this cookie on every request it's going to take the value of that cookie it's going to say okay look up this session id in the session store which is the database and then it's going to say is the session valid if so let's use the information from the session to either authenticate our user find out some data about our user maybe like how many times that user has visited our site anything of that sort is what's going to happen when the user loads a different route you'll also see that we have an expires property right here that says tomorrow this cookie is going to delete from the browser but for now since it's still valid it's going to attach to every single request so if we go to the network and look at that last request we'll see that in the response header this came from our express server using the express session middleware we have the setcookie header and we set the connect.sid header and we gave it an expires now in the request headers since we only did this once you won't see any cookie but if i click refresh one more time and we look at the request headers and response headers you'll see that in the request headers we have the cookie that was set previously so in other words the browser is saying okay i have a cookie that is still valid let me attach it to every ques request within this localhost domain all right so we have this cookie on every request now let's see what's happening on the back end so let's go back to our code and we're in the shell so we're looking at our database right now and we're going to type in db oh let me clear this real quick db.sessions.find and that's going to look in the sessions collection for any documents in that collection and you'll see that we have one and only one document which represents the session that we just established in the browser so you'll see that the id is right here which you can also see in that cookie that we have in the browser so let's see the first couple letters were capital a y yj so let's go back to the browser and you'll see that the cookie right here is has got that id set in it so that's how we kind of connect the back end to the front end and then let's once again come back to our code so we also have the expires header within here so we can also validate it on the back end and basically what this is going to do is every time the server gets that specific cookie with that session id attached to it it's going to come to this sessions collection in the database it's going to grab that document out of the database or the session store and it's going to get information that we have set on to that session and use it to do whatever we want to do with our application now this is great and all but what do we actually use this express session middleware for well in another video in this passport.js series you'll see how passport.js actually connects in to the express session middleware and uses the session to actually authenticate the user but since this is kind of a standalone video i'm not going to get into that all i'm going to show you before we kind of conclude is where this session is being set now we know that the cookie in the browser has the session id and we use that session id to look up the session in the database or the session store now we can also come to our routes and get information about the session so if we said console.log request dot session you'll get to see exactly what that session looks like and we can actually set properties to that session so again i'm connected using nodemon so we'll automatically refresh when we save this app so let me click control s to save you'll see that something happens here so we reset and now if we visit this route again in the browser in the console we should see the session object so let's quickly switch over to the browser we'll refresh refresh this page and then we'll come back to our code window and you'll see that our session object has been printed to the console right now all we have is a expires header and a couple other metadata properties but what we could also and this is set to the cookie object but we could also set other information so we could set something like how many visits a user has made to our page so let's go ahead and do something really simple like that in our only route that we have for this application let's just say if request dot session dot view count we want to say request dot session dot view count equals request dot session dot view count plus one or you could just do the plus plus syntax at the end you could just do something like that and be done with it but we'll be really explicit here and we'll set a value okay so if we have that property on the session we're going to increment it by one and then what we're going to do is we're going to say in the response instead of hello world we're going to say you have visited this page x amount of time so we'll use a little javascript syntax and we need to change these to backticks to get this to work and let's see we can just put in request.session.view count and now it should tell us how many times we've visited this page when we visit that page now we also have to say else because in this first occurrence we're not going to have this property set so if that does not exist then we're going to say request dot session dot view count equals one all right so we have set a property to the session object and let's go ahead and save this application and go to the browser and visit it so we're in the browser now and we will reload and it says you have visited this page one times it should be time but now every time we refresh we're going to get that number to increment because of the logic that we've put into our route so you can see how this session object could be very useful for tracking information about a specific user or client one last thing i want to show you if we go back to the code you can look it up in the database again so let's go back to and let's find that session once more you'll see we still have just one object one document in the database but now we have this little property down here so when we set the view count property on the request.session object that actually persisted in the session store or our mongodb database under the view count property so again you can see how powerful this is and you could also kind of extrapolate out and start to foreshadow how something like a passport js middleware could kind of connect into this middle this express session middleware to keep its own sort of data you came here to learn user authentication and it took us about two hours to get to the part where we're actually writing it for the first time i hope the prerequisite lessons that we just covered were really helpful to get us set up to this point and now we're ready to actually implement the passport local strategy within your web app your users are going to have the expectation that you have the option to do a username or email based authentication you have to have this because what if your user doesn't have a google account or a facebook account to use that you know other authentication option that you're offering you've got to have this most basic option for them and the passport local strategy is one way to do it equipped with our knowledge of http headers cookies the express session library and express middleware we are fully ready to jump into this strategy my goal in this video is to get the passport.js library imported into our express.js application and can start to configure it to help us with this i've set up a repository on my github that will basically give you a starter template to work from and what this is going to do is kind of eliminate all of that stuff that we don't want to focus on such as setting up a basic express application setting up a very basic database with mongodb and even setting up something like a express session which we talked about in one of the prerequisite videos for this tutorial series in this repository i've got three branches but the master branch is going to have your starter template so if you don't know how to use branches in git that's totally fine if you do want to learn more about that i actually have a full tutorial series on using git but anyways you can see if you come into github you don't have to actually know any commands to do this you just drop down and you can see that the different branches will have the final branch is kind of the final implementation um no promises that will get you know line by line character by character to the same implementation here during the video but will come very close the overall structure will be exactly the same and then we have the final all-in-one which is basically just one js file or javascript file that has everything that you need to run this with tons of comments so that you can really figure out what is going on so that's what the repository is you can go ahead and fork it or clone it whatever you want to do and then download it to your computer and once you've done that you should land to a screen like the one i've got right here and i've got open the readme which kind of gives you basic instructions on how to use it we went through most of this already so let's go ahead and close that out and take a quick tour of what's going on in this repository and then we will go into the configuration of the passport local strategy let's take a quick look at what i've got for you already set up in the template application it's pretty similar to what you probably have seen before i tried to make it a similar structure to what you might find in a lot of online express node.js tutorials so hopefully this looks a little bit familiar but anyways we start with our app.js which is going to set up our basic express app so the imports at the top let's just go through them real quick if you haven't installed them after cloning the repo just type npm install to get those installed we have express pretty straightforward mongoose which is the odm for mongodb i will mention um while we're on this line i've already got my d service running in the background so you'll have to do that when you're running this app and i i don't even know if i have this in the readme so maybe i will put that in here right now we'll just say make sure to run the mongod service before running the app locally all right so now that we got that covered just make sure that you have that running and then you should be able to run this app just fine um all right so moving on we have express session which i've covered in a separate video how this works and how to set it up so i've already implemented it here for you if you want to learn more about that go to that video again that is in the description just click on the playlist and you'll you'll find it so next up is passport this is what most of this video in the next couple videos is going to be about will require in the built-in node.js crypto library which is going to allow us to create and verify passwords we require in the routes which is the routes folder we'll get there in just a second and also we have a database configuration in the config directory now coming down we have store directly related to the express session middleware again that's another video we have this little line right here most people probably have seen it but if you haven't all this is doing is giving us access to the dot env file that we have defined over here that by default is not going to be imported when you clone this repository because it's got secret keys in it so you will need to create the dot env file and in the env file i think you only need two things you need the db string and the secret and for my case i'm just using a very simple db string i don't even have a user or a password just to keep things simple for now but in production you'd obviously want to um have a user and password in the actual database that you would connect to so and then the secret is going to be i think for the express session module so let's close that and then you can see you can actually get access to those variables anywhere within this app.js file with this syntax the process.env.variablename all right so moving on we have the express application pretty simple this is some middleware for parsing http responses most of you would probably have seen app.use bodyparser.json but i've just used the built-in express parsers because i think these actually came in a little bit recently in like a recent release i could be wrong on that um but you no longer need to use body parser all right session setup again this was covered in a different video but let's just take a very very quick look at what is going on here we have our session store which is going to say hey express session middleware i want you to use the mongodb database for the session storage and in that i want you to use the sessions table or not table but collection in that mongodb database so that's the session store down here in the configuration options for the session middleware we are telling it to use that store then we have some other options here so the secret we just talked about that that's going to help the express session middleware validate the session that it has looked up it's going to check to see if it matches that secret these two options have to do with you know how does the session treat or how does the session react when there's actually no changes in the browser you can read up about that on your own and then finally the cookie this is the this is also another separate video in this series but basically what we're doing is we're storing the session id in a cookie in the browser and this right here is just going to kind of tell the express session middleware hey i want you to it basically set an expires header um not header but an expires property of one day so this cookie will expire in one day and a new session will have to be reestablished when it does expire alright that was just a quick overview if you want more you have to check out the other video next up we have passport authentication i've just put in this basic require statement to show you where it is so it's in the config directory we'll get to that in just a moment we are using our routes so this is pretty standard in express you put your routes after the other middleware but before your air handler in this case we don't have an error handler you might want to do that for a production application finally we are listening on port 3000 localhost pretty straightforward so that is the basic app let's go ahead and look at some of the other pieces so let me save that we'll first start in the config so we have passport.js all i've done here is imported the relevant modules that we'll will need to set it up and then i've imported some database configurations uh well the connection and then the user model that we'll be um using so going straight over to the database configuration this is a pretty standard mongodb database setup we're requiring in mongoose again we got this access to the env file we're going to grab the db string from that file and we're going to create a connection with it so we pass in the string to the create connection method on the mongoose object and then we pass in these options which will just suppress any warning messages finally we have a user schema it's very simple we just have a username hash and salt you will see what the hash and salt mean a little bit later so we create a model for that user based on the schema and we export the connection so that we can use it in other files so pretty straightforward with that let's see what else we've got we have the password utils which should just have the validate password and create password functions so let's check that out and you can see that i've already kind of templated out what the functions will look like all we have to do is jump in there and actually implement them let's see if i'm missing anything else okay i've got the routes just one route file and i know there's a lot of stuff in here but really there's not much of anything we pass in the express router uh passport because we're going to actually use passport in our routes we have some past password utils we just looked at the database connection and user model and really what we're going to be doing the only thing we're going to be doing in this file is these two routes so the login and register route we're going to have to implement the logic behind these in the git routes below all i've done is create a super simple flow that will go through as we implement this passport authentication so you'll see the home page is just going to tell you to please register you click the link goes to the register page which is right here that has just a really ugly looking form that we will type a username and password into to register that will submit to our custom implemented post request up here then it will if you're successful it will redirect you i think to the login page then you will log in with your username and password which will create a post request to the login post route which we have to implement and if you successfully log in i think it will redirect you we're going to have to write this logic but it will redirect you to i believe in the i believe the login success route so it'll say you've successfully logged in then we'll try to visit a protected route and that will be right here and we're going to check if we're authenticated and let you in if you are so basically you can look at this but it's just a flow of pages that we're loading the reason i did this without using something like ejs or another temple templating language is just to keep it as simple as possible all we're doing is passing basic html and html forms and using the built-in express methods like res.send in res.redirect so hopefully that makes sense if it doesn't take a look at this for a few minutes and i know it will before we get into the actual implementation and configuration of passport i wanted to show you again i know we already touched on this in the first video just for a few minutes but i want to show you how to find the documentation for this i personally had a very difficult time finding kind of an end to end tutorial and documentation for passport and i think since all the strategies are developed by different developers there's not really you know a one size fits all documentation for it now if you go to the passport.js website you'll first find that you can click strategies and browse through all the different strategies you'll be able to go to those pages but in our case we're using the passport local strategy so if we click this we should be redirected to the passport local strategy it's going to give us some basic usage instructions so we install it we configure it with a verify function and then we can use it in the route here but that's pretty much all that it gives us there's actually a couple more steps that you need to do to use the um local strategy which is kind of weird why it's not in this on this page and if you click on the examples it goes to a 404 page i think maybe that was recent i don't know whatever the case this is actually not where you're going to want to go for documentation on the passport local strategy the passport local strategy is actually better documented in the general documentation of the passport.js middleware so if you go to documentation right here and you click username and password this is where you're going to get a little bit more verbose documentation on the passport local module so here we have the same thing install passport local but here we're getting a little bit more detailed implementation of this verify callback and how you would use the form how you would use it on the route what kind of parameters you can pass to the verify callback so this is a little bit better documentation but it still kind of misses some of the configuration that you have to do for this module so i'm going to show you exactly how to use it but you can kind of peruse the passport.js documentation you'll find a few things for example if we click on configure it's going to tell us how to configure a strategy because being a framework for the middleware passport has kind of a standardized way to integrate different strategies so on every single strategy that we use we're going to need a verify callback so in this section kind of talks about that verify callback and what the different responses are required based on how the user you know whether the user entered the correct or incorrect credentials whether we got an error message whatever the case it tells you that and then we also have documentation on the authenticate method so passport actually provides you with a built-in authenticate method on the passport object and all you need to do is provide it with the name of the strategy that you've defined and then passport figures out how to go find the verify callback that you've configured for that specific strategy i know this sounds like a lot and i know this documentation is a little bit sporadic it's not necessarily you know a b c d one two three four it's it's a little bit confusing so let's just get into the implementation and i'll do my best to kind of document the passport local strategy for you like we saw in the documentation the first thing we need to do is define the verify callback for the passport local strategy so we'll do this in the passport config file and all we need to do is comment this out the passport.use method and pass in the strategy and the verify callback so i'm just going to paste in the full thing real quick and you'll see that this looks pretty similar to what we saw in the documentation it's also going to be pretty similar to what you'll see in a lot of tutorials but i personally find this a bit confusing when we're looking at it all at once so let's go ahead and deconstruct what's going on in this configuration put it in some variables so that we know exactly what's going on all right so the first thing that we need to do is define the strategy itself so let's say strategy equals and then in this case it's going to be the new local strategy all right so that is the most basic way to create a strategy and then this strategy is going to require that verify callback so let's define that above here and the verify callback is going to take a couple parameters it's going to take a username password and done function in this case down here i just called it callback but you it doesn't really matter what you call this all you need to know is that this represents a function that you will eventually pass the results of your authentication to so those are the parameters and they will actually be populated by the passport framework based on how you implement this so we expect the username to be the value that we received from the request body of some sort of login form so if we were to create a login form type in our username and password and then make a post request to the express api that post request is going to have a username and password field and passport is going to automatically look for those two fields and grab the values of them and populate them in the verify callback now there's a little bit tricky part to this because if you don't name your username and password fields exactly this username and password the passport um framework is not going to or not the passport framework but the passport local strategy is not going to know what variable to look for so in order to prevent this we can actually define custom fields that we want passport to look in i'll show you how to include this in a few seconds but first let's just get it in a variable so we'll say custom fields is equal to an object and we'll say the username field is going to be uh you name we're just making this up making it custom so that we can see exactly how this works so our username field is you name and then our password field is just going to be something like pw so obviously these are some non-conventional ways to name the password and username fields but if we define them in our custom fields object then passport local will know where to look alright so we'll use that object in just a second but first let's come back to the verify callback so in the verify callback what we're doing is basically our own implementation of a password verification now this is where i think people get tripped up a little bit i know i did um thinking that the verify callback has to be a very specific structure and we have to use a certain database because of course the documentation online shows that we're using the mongodb database but in reality it doesn't matter what database you use and it really doesn't matter how you choose to verify the credentials all that matters is that the return values that you pass to this done callback are what passport expects so we can come in here and do whatever we want but for simplicity as we know i'm using the mongodb database so it's going to look pretty similar to what you saw in some of the examples so let's go ahead and copy this so i think we're done here with this copy paste and then we can put it right here and all we're doing is going to the mongodb database and we're looking for a user that has the username provided in this parameter so again what's going to happen we make a post request and we provide a json body with you name and password then passport as a middleware is going to look for these two fields finds them takes the value and populates these two parameters with those two values so at this time when we're executing this callback these represent the username and password so we can look up the username in the database and then just in a basic promise we are returning the user so we check if there's a user in the database you know if someone has actually registered already then or actually it's the opposite if there's not a user in the database then we're just going to return this should be updated to done to represent this done callback up here and what we're telling passport here is that no there was not an error in this operation but there was also not a user so go ahead and reject this and so passport will return i believe it's a 401 on unauthorized http status so that's the first check we need to do then um we need to check whether this is valid sorry for all these comments i had them in here before when i was writing this out so we have a variable here that says is valid and for right now we don't know how this works and this is not even a function that we've defined yet but basically what we're doing we can comment this out for well let's not comment it out yet what we're doing is we're putting the password through some sort of verification function which is going to um or we're also putting the hash in the salt stored in the user record in the database and we're verifying those two things against the password you'll see how that works in a minute but basically let's just assume that this returns true or false which it does and we say if the password if the login credentials are valid then we're going to return the callback let me update this real quick again these are just corresponding to this parameter that passport provides we're going to say nope there was no error and yep there was a user and this user was successfully authenticated based on my verification function so when we pass this to passport it's going to let us into the route and then finally if it's not valid we say nope there is no error but we did not verify this user correctly don't let them in the route and then finally we using the promise syntax we're just going to catch any of the errors that happen within the express application maybe on the database side of things and if we get an error we're just going to pass that to passport and it knows how to handle that so that is the basic verify callback and i'll show you really quickly what is actually going to happen here when we use it in a route so let me save that and come back to one of our routes so let's go down to the um the post login route so what we're going to do is include a middleware in the post login route called passport.authenticate and then in the authenticate we're going to say um the local strategy and we're going to pass in um well we can we can worry about the rest of this a little bit later all i wanted to show you here is that we're passing this middleware in the login post route and so basically what's going to happen is we make a post request to log in with our username and password and then that gets intercepted by the passport middleware and then we come in passport populates these two objects it runs this function so we're looking up the user in the database validating the credentials returning some sort of response and if we get this response right here where we populate a user then it's going to go to the next part of this function and it lets us in the route so that is the basic implementation of passport and now we're going to tie up some loose ends and make sure that it actually works and then we'll see it run live we just have a few more things we have to do to get this working um the first thing i forgot to do when we finish this up is actually complete this verify callback so we started with passport.views and then we passed in all of this stuff so we need to actually do this now um so the first thing that we need to do is let's see we have our custom fields and our verify callback so in our new local strategy we're going to pass in our custom fields and our verify callback and then we're going to say passport.use and then we're gonna pass it in that local strategy so now we actually have it configured and in app.js when we require it in somewhere um let's see where do we do this right here in the passport authentication we require in the configuration and what that's going to do is basically just take this line right here and include it in the app.js now that we've got our strategy configured we've done the bulk of the work there are a few extra things that we're going to have to put in here but i'm going to go ahead and just copy them in um and then we're going to come back to them a little bit later after we have everything working to understand them a little bit better so at the bottom of this configuration i'm just going to paste in two initializations and this is the passport.serialize user and deserialize user now this has to do with the express session and how we put a user into the session and grab a user out of the session basically what is happening is we're going to put the user id into the session and then we're going to when we want the user to come out of the session we will grab that user id that was stored there and find it in the database again we're going to come back to this so don't worry about it if you don't understand it i think this these two functions are a little bit tricky especially because there's not a whole lot of documentation around them so let's save that let me save this real quick let's come back to app.js and add in our last two lines that we're going to need before all of this is going to work so right after we require in the passport configuration we're going to say app.use passport.initialize and again what this is going to do is kind of initialize the passport middleware and um basically so that it doesn't get stale so we might be using different routes we might click to several different routes and if we don't reinitialize the passport middleware then there's a chance that hey maybe the user um maybe their session expired or something in the time that we're doing that it's just always safe to refresh the passport middleware every single time that we load a route and so that's what this is doing and then we need to put in passport.session which has to do a little bit with what we just talked about the serialize and deserialize user but um more so it has to do with the actual express session middleware so i know we talked about this a little bit earlier we also talked about it in a separate video but the express session gives us access to the request.session object and anything that we store on the request.session object inside any of the routes is going to be persisted to the database under the sessions collection so knowing this passport cleverly kind of plugs into that and bootstraps off it and uses it as a user authentication mechanism so we're going to actually go through this along with the serialize and deserialize user in a few minutes but for now let's see if we've got this working we still have a few things to do in the routes before it's going to work but let's save it and actually run the app i'm going to run this with nodemon so we have live updates so nodemon app.js and doesn't look like we have any errors at the moment so there is a chance that we have this working the first thing that we're going to have to do before the passport middleware is going to be effective is finish defining the password verification and generation functions so if you remember in the passport configuration in this verify callback that we had defined we called this method called valid password but in this module we haven't actually created this valid password function so it's not going to work as it stands right now we're going to have to go over to our password utils file and define both the valid password and the gen password functions before anything's going to work we're going to open up password utils in the lib folder and you'll see that i have basically templated out the two functions that we're going to need but to understand this i've actually put a slide together so that you can visualize which at what's actually happening with the generate and validate password functions we're going to be using the node.js crypto library to do this but before we get into the actual like what methods we're using it's better to have a conceptual understanding on the screen right now is a basic representation of how we generate and validate a password to a database now the cardinal rule here is that you're never going to store a plain text password in a database that's kind of web application 101 i think everyone is pretty familiar with that but actually figuring out how to do that is a little bit more complicated now we talked about earlier how the passport.js middleware does not give you a specific way that you need to do this it gives you a lot of freedom as to how you might generate and validate the passwords that the users are providing in the login and register forms as we go through this just note that this is not the only way that you can go through this process there are other libraries other than the node.js built-in crypto library there's also different types of logic that you can go through but i've tried to keep it as standard as possible and kind of in line with what you would call best practice so anyways what's going on here is we have two steps in the process so we have the creation of the password and the verification of the password you can think of this as the register and the login so you're sitting there behind your computer you found this cool new web app and the first thing that the web app is going to ask you to do is register you need to give them a username and a password and then maybe a couple other things like an email first last name maybe even an address or something but what's important is that you are providing that web app with a plain text password you're just typing that into a field and when the web app receives that password it is still in plain text form we can't really avoid that that's fine but what happens is we need to transform that into something that we can actually store securely in the database without worrying about some hacker you know taking over a database and grabbing all the you know users passwords in that database once the user information is stored in the database we can move on to step two which is password verification now in step two you can think of this as the login process so when the user sits behind their computer and is typing in their username and password to log into your web app that's going to be the verification step and what's going to happen is they're going to provide you with their username which you're going to take and you're going to look up that user in your database using the username or maybe an email once you find that user in the database then you're going to have access to this password hash and the salt that we stored before so you're going to pull both of those values out and along with the password the plain text password that the user just provided you you're going to put those values through the same exact hash function so you pull the salt out of the database from that user and you put in the plain text password that they just typed in and so in this case we have the same exact values for these parameters as we did when we created the hash in the beginning and we know since a hash function is always going to give you the same exact value if you put the same parameters into it we know that we can generate a password hash and compare it to the hash that we stored in the user record in the database and if those two values match then we know that we have validated this user and that they have entered the correct credentials we've got a conceptual understanding of this process so let's go ahead and code it we're going to come back to vs code again i've set up the functions in the parameters that they require right here and we're going to start with the generate password function which is the step one of the process so this password argument is going to come from the user when they type their password into the register form and then here is our implementation now i'm going to walk you through this um we're using the node.js crypto library and the first thing that we're going to do with that is generate a salt which is just a pseudorandom value and it's going to add a bit of randomness to our generation of the hash so we have the salt then we pass in the plain text password and that salt to the pb kdf2 method on the crypto library and then this last part sync just means synchronous for synchronous operation and then the 10 000 right here is going to represent how many iterations we're doing 64 is how long or how big this hash is going to be and then right here we specify which hashing function we're going to use finally we will convert this to a hexadecimal string now down here we just return those two values and we are done with this piece of the implementation to learn a little bit more about what we just did i'm going to pull up a document on google this is from the internet engineering task force and it's just basically a specification for different cryptography methods and or password-based cryptography methods and if we go down to the table of contents we can actually find the pbk specification which is what we were using from the node.js crypto library and you'll see that this is actually going to well we might actually be in the wrong spot here we're in the appendix see if we can get somewhere a little bit more straightforward okay we clicked on the wrong one here so we need to click on 5.2 and this is going to show you kind of the template for implementing that kind of function so the node.js crypto library is just implementing this standard right here and we can actually come up and see some information about it so i think there's something on iteration count it says that they recommend at least a thousand we put in well you want to have 10 million for a super secure implementation we are somewhere in the middle with 10 000 which should be fine and then it also talks a little bit about the salt up here and you can read up about what that actually is a lot of this is just math so i don't want to get into it but this is kind of where the standard comes from so we're not just using some random crypto function this is kind of what the engine internet engineering task force has designated as this is how you should do it when you are verifying and generating passwords we can now come back and do the second function which is the valid password i'm not really sure why i called it valid password probably should be validate password but anyways here is the implementation for that all we're doing it this is basically the same exact thing remember what we went through on the slide we're just creating the same exact hash that we did up here except this time we're receiving the hash and the salt or well we're just passing the salt but we're getting that salt from the user record in the database and then we're getting this password when the user types it in in the login form so given the same inputs we should expect the same output and therefore we are going to return whether the hash that comes from the database is equal to the hash that we computed using the password that the user just provided us in the salt that was in the database for that user record so we're going to either receive true or false and this is what we're going to put in our passport js verify callback so let's save this and come back to our passport js configuration and you'll see that we're already using this right here we've already set it up how we want to we just need to import it so i'll do that right now so we'll say valid password equals require lib password utils dot valid password because we've exported them here at the bottom so now our passport.js implementation is complete and it should work with our application once we implement the two post routes for login and register so let's do that right now we'll come to the routes and you'll see that we have the login and register routes they're not implemented yet so we need to do that it's pretty simple so i'm just going to paste in the implementation most of this is just creating a user record in the database but we're also going to be implementing that first part the gen password function in this register route i think i have it yep i have this already imported but let's go ahead and rename it we'll just say gen password to stay consistent and then we need to grab the gen password function off of the import so now that we have that we can implement this so here's the implementation we'll walk through it really quickly i want to point out a few things before we get started we are grabbing the password and username values from the request.body.pw in unname fields if you remember from the passport configuration just to demonstrate the options you can do we went ahead and customized what we're expecting to see from that request.body object so we need to stay consistent and we need to use those to grab those values so you can see what we're doing here is we are generating that salt hash object so it's just an object with the salt in the hash so this one right here and that's coming from the gen password function that we just imported up here from the password utils then we are going to create a new user object for the database we're going to save that user we'll go ahead and just console log it to the terminal and then we are going to redirect to the login route all right so we have implemented register and we can go ahead and try that out in the browser so let's run it run the application looks like we don't have any errors so let's jump back to the browser type in localhost 3000 slash register or actually we can just go to the home page and it gives us a link to the register we're going to enter our username and our password i'll just do one two three to keep it simple and we'll submit it looks like it properly did something let's come back to the terminal to verify that good news we see the object that we just created we put the username in there and then the hash and the salt that we got from the gen password function and then we can also check the database so let me just open the shell and we'll look it up so show databases we are using the tutorial db based on the dot env file so i will say use tutorial db and then we can say db dot users dot find and you should see the user that we just created so clearly we've got the user in the database and the last thing that we need to do in this entire flow is implement the login route so if we come back to what we're already in the file we have the login route that we've already kind of put this passport.authent method in a little bit earlier but i just want to add a few things to it and we'll actually simplify this a little bit as well the first thing i'm going to do is pass in a second argument to the authenticate method and this is just going to be an object that tells passport where to redirect based on the status of the login so if you remember the passport.authenticate method is literally just going to look in the passport configuration for this verify callback and it's going to call this function right here and this is going to return either a user if we are validating the user correctly and the user has provided the correct password or we're going to say false and in that case it's going to redirect to the login failure so really since we're adding conditions for both a success and a failure we don't need this last function right here so we've just included this normal callback that we see in most express routes but we don't need that in this implementation and we are pretty much done with the login post request so let's save this and give it a try in the browser we'll type in the same user that i did earlier one two three for the password and submit and it says that we have successfully logged in so something worked here now we can go to the protected route it says you are authenticated we can log out and reload now we're not authenticated and we can log in again so we can just go in this circle here it's kind of how i set it up so that we can see that flow but i'm going to be talking a lot more about how this is actually working and how you can use the passport middleware in your routes in the next video but let's come back one more time to the code and just kind of take a look at the routes that we just went through so we started at login login submitted the data that we put in there and the passport verify callback was called we successfully validated the user so we got to right here and then we come to the route the login post route and we had a success so we are going to come to the login success route you can see this success redirect login success so we'll come down here somewhere so we came to the login success then it said go to the protected routes we clicked that link and we came right here which you'll see a little bit of extra syntax we're going to go through this in the next video but this is how we would authenticate the user once we've run through that authentication flow in the login post route and then we can also log out so we've got a logout method on the request object and then the cycle kind of repeats we are officially done with the passport configuration we've got it working completely and this is all you're going to have to do for the passport local strategy to authenticate users into your web app now i did mention earlier that we were going to come back to something and it was in the passport configuration here at the bottom so these two methods the passport.serialize and deserialize and then also i think in app.js we have these two lines the initialize in session now we don't really know how those are working and i promise that we'll come back and explain how those are working and kind of see it for ourselves in code i would also like to go through some of these things like request that log out and request that is authenticated and understand what is going on there and also kind of understand you know you would intuitively think well we're probably just going to use the passport dot authenticate middleware on every single route that we want to authenticate but that's not the case for the passport local strategy so to start what we're going to have to understand is that passport.serialize and deserialize configurations so if we open up the passport file it's these two configurations right here that we need to understand to really grasp what passport is trying to do in order to understand this a little bit better i'm going to open up app.js and we're going to write a very basic middleware that is just going to give us it's not going to do anything but it's going to give us a little bit of debugging power so we've got these middlewares working so here's where we set up the session so we include that here then we include the passport.initialize and passport.sessionmiddlewares right here so after those have done their work these are happening on every single route request we'll put in our custom middleware so we'll say app.use and we're going to pass in a simple function we're just going to give it the standard parameters and then what we're going to do in the body of it is just console.log request dot session and then we will console.log request dot user so you'll see how this works the express session is going to create this object right here and the passport middleware should create this object here and then finally we have to call next so it doesn't crash our routes but basically every time we visit any route in this application this is going to run and we're going to see exactly how it's working so for starters let's just get this running and visit in in the browser so we'll come to google chrome we'll come back to what i've got on the screen here in a second let's just go to the base route so we're at the home page and you can see in the application here is our cookie that we've set which represents the express session id so that will we're going to just delete this really quick so that we refresh everything so now we have a clean slate and the express session middleware is going to recreate a new session for us to use when we press refresh so we pressed refresh it created a new session and in the console we should see that printed out because of the middleware that we just wrote right here so you see the session is going to show us the cookie and that's pretty much it you'll notice that the request.userobject is undefined right now and that is because we haven't yet authenticated our user using the passport.authenticate method so let's do that really quickly in the browser so we need to actually just visit the login route because we've already got this user in the database if you remember from last video so we will sign in and click submit and this is the same session id come back to the code and this time we've got a different story so this time let me expand this so we can see it so here was our first go around so this is what it printed and then this is the second time so now we have the session with the cookie but we also have this line right here and this was created by the passport middleware and when we executed the passport.authenticate method which is in the login post route so right here that's what we just did and what passport did behind the scenes was create this additional property on the express session and how we got this right here is through the passport.serialize user function so right here we ran the serialize user function we passed in the user id and we stored it under the user property so let's go ahead and check to see if this is the actual id of our user so it's 5e0f now let's go over to the shell and we're already set up to query this so we'll say db.users.find and you'll see that we have the 5e0f user in the database so the serialize user function when we did the passport.authenticate method is going to grab that user from the database get the id of the user and then insert that into the passport.user or actually it would be the request.session.passport.user property so now when we need to grab this user from the the session we're going to use the deserialize user function so we're kind of seeing it all at once but to populate the request.user right here this is the middleware that we just wrote to print all this stuff to the terminal in order to populate the request.user we are going to grab the user from the database right here and based on the user id that was provided in the session object and then we are going to attach the found user to the request.user object so that was a mouthful and we've got a few more pieces to this puzzle so we'll come to app.js and these two lines are playing into this equation as well so when we say passport.initialize that's going to kind of re-run everything that we just did and then the passport.session is going to kind of work in the same way so every time we load a route these two middlewares are going to work together and what they're going to basically do is they're first going to check to see if this user property is not null so it would look something like this we would say if request.session.passport.user not equal to null then we are going to know that there is a logged in user and we're going to grab this user id from that property then once we grab that user id from the property we're going to use the deserialize user method pass in oops pass in the user id grab it from the database and then what we're going to do is populate the request.user and set it equal to whatever user we got from the database so that's basically what is happening on every single route request now if this user object is null then that means that the user is not currently logged in and we do not grab the user from the session and this property request that user is not populated if we go in the browser and we do the log out function or we visit the logout route you're going to notice the next time that we console.log these two properties that this user object is not going to exist so let's scroll to the scroll to the bottom save this um come up here so we're at the bottom let's go to the browser and first we've got to visit the protected route and when we click this button right here it's going to log us out so we click log out and reload and come back to the terminal and now you'll see that this passport object is going to not have this user property in other words we are not logged in now you might say okay this is a lot to look at and it's a lot of kind of funky logic to go through every time we want to figure out if our user is logged in or not and luckily we have some methods built onto this request object to kind of do this logic for us these methods were defined by the passport middleware or the passport local middleware and we can see this if we visit the repository so this module the request.js module is where this is going to kind of happen or where these are defined and you'll see a couple properties attached to the request object so the first one is the login property and this is actually called by default when we use the passport.authenticate method so we don't really have to ever use this on our own if we're using the passport.authenticate method now what's useful to us is the last three properties so first we have request.logout so anytime that we want to log our user out we just call this method and you'll see that i do this when we had clicked that logout button you'll see in the route for the log out route somewhere down here so here's my logout route and you can see that i have called that method right there which is basically going to delete the request.session.passport.userproperty from the session so that's all that that's doing and then next time we call the passport.initialize and passport.sessionmiddlewares which happens on every route it's going to check that property see that it's null and pretty much declare that the user has been logged out all right so the next one we have is the request dot is authenticated and this is a really common one we're going to use a lot and basically all this is doing is what we went through manually and there's a bunch of funky code here because it's part of the framework but basically all this code is doing is saying does the request.session.passport.userpropertyx property and is in it is not null and if that is the case then we declare that the user is authenticated because the only way that that property would have been populated is after we use the passport.authenticate method which is going to run the verify callback which is going to implement our custom login logic finally we have request that is unauthenticated i don't really use this it's just the opposite of the request that is authenticated so you can use it but it's not really all that complicated so we've got these methods unfortunately these are not documented very well in the passport documentation which is kind of a shame but anyways let's come back to our code and see how we might use these properties to our advantage so right now in our routes we are manually calling these things and right here we are manually checking whether the request is authenticated and then if it is we are doing something if it's not we're doing something else so in order to streamline this a little bit it would make a little bit more sense if we included this as middleware and all we're doing is checking if the user is authenticated and if the user is authenticated we just call the next callback and it goes into the route and if the user is not authenticated we return some sort of 401 unauthorized error so to make our lives a lot easier let's go in the routes folder you can really put this anywhere i'm just going to put it in the routes folder and we'll just say off middleware.js and in the off middleware js i'll just take you through two different middlewares that we could implement you can get as creative as you want with this but here are some pretty standard ones that you might use so we'll say module.exports dot is off equal to a middleware function so there's the standard middleware parameters or arguments and then we're going to do something in here to check whether the user is authenticated and if they're not we're going to return some sort of 401 unauthorized error the second one we're going to do module dot exports dot is admin so currently we don't have an admin property on our user schema but we could easily add that and we could use this middleware to basically check whether the user is logged in and is an admin so that can help you kind of protect routes that are for admins only versus regular users we'll get to that in a second but first let's get this one done so all we're going to do is use that request dot is authenticated method that is attached from the passport middleware so we'll say if request dot is authenticated then we're going to just say next and pass it on to the next middleware in the chain if the user is not authenticated we'll just return a 401 unauthorized error so we'll just say res dot status 401 dot json and we'll just put in a message that says you are not authorized to view this resource all right so that's pretty simple so if they're authenticated if they're logged in we're going to just pass it on to the next middleware in the chain if not we're going to just stop it right there and return an unauthorized error all right so let's test this out so we have the is off middleware if we come to our route let's do this let's kind of refactor this so in our protected route we're going to return res.send you made it to the route so something to indicate to us that we successfully made it into the route and within this route we could do whatever we want we could return some sort of data and to do this we will just pass in is off as the middleware right there and of course we need to import this at the top of this file so we will say is off equals require off middleware dot is off all right so we've got this set up and now if we try to visit the protected route we should hopefully see you made it to the route so let's try that go to google chrome and we're already at our protected route so oh it looks like we are not authenticated right now because we had logged out so let's log in really quick so we are logged in and when we click go to protected route we should see that message that we just put there it said you made it to the route so our middleware is working now let's visit the logout route so that we can log ourselves out and then see if that other status is going to work so now we went to the log out route and we were redirected to the protected route i'm not exactly sure how that worked but we got the error message that we were expecting and if we were using you know a front end we could kind of process this error in a clean manner and give a friendly message to the user so we've got our middleware working and now all we have to do is pass in this short variable before any route that we want to protect so the next thing is just kind of an added bonus it's not necessary for all applications but it's something that kind of just stretches your creativity a little bit it gets you thinking outside of the box and we're not just constrained by some framework that tells us that we need to do it this way so in order to implement the is admin we are going to come to the database and add one more thing to this user schema so we're going to add an admin property which is going to be a boolean and we'll save that and then we need to actually register a new user so that they have this admin property and we'll just by default put this new user as an admin um let's see where that happens is going to be in the register route um where are we okay so right here is where we're going to do this currently we're just passing in this data but i'm just going to hard code in the admin property and we're going to say true so save that we will come back to the browser and we need to go to the register route so let's go to register let me get rid of this and i'm going to say zack 2 and we'll do the same password one two three just so i don't forget it submit we have put this user in the database let's go ahead and check that just really quickly to make sure so we'll come to the shell db.users.find now we have two users in the database let's kind of extend this and the second user zac2 has an admin property of true so zack the original zach is not an admin because we haven't added that property the second one is an admin so the first user should be able to visit an admin route while the second should not so let's test that out really quickly we need to make a route that will actually test it so let's come down to protected route just copy that and instead of protected we'll say admin route so the first thing we want to check is the is off we kind of have some freedom how we want to do this i'm going to go ahead and simplify things and just say is admin so we don't have to repeat it so we could do is off and then is admin and in the in in this middleware all we have to do is check whether that property exists but i'm going to go ahead and simplify that you'll see what i mean in a second so we'll say is admin we need to import that here at the top so i know this is you know not really good coding practice we could refactor this a little bit but we'll do it just for the sake of time so we've put the is admin middleware in there we've included it in the admin route and we'll say you made it to the admin route if they successfully make it through that middleware gate so now we come back to the auth middleware and let's just copy the same exact thing except this time we're going to say if request dot is authenticated and request.user.admin since this is a boolean property we can just say this so now we have two requirements to get through this authentication middleware and then we have the same exact um logic here maybe we'll change the message to say you are not authorized to view this resource because you are not an admin all right so we've got this set up and i think we should be able to visit the route that we just created so admin route let's just manually type that into here and since we haven't i don't think we've logged in with anyone yet so let's log in with the first user so this one should not be an admin and we'll go to the admin route and it'll say you are not authorized to view this because you're not an admin as we would expect now let's log this user out by just going to log out and then let's go to login we're going to log in that second user that does have admin privileges oh looks like we had some sort of login failure maybe i just typed it in wrong um oh it was because i put the wrong username in so it's not zac one it is zach2 and one two three all right we are successfully logged in let's go to the admin route and this time we should get a success message you made it to the admin route so we've covered a good amount here but hopefully this kind of opens up your creativity into understanding how the passport local strategy works how we can use it to creatively authenticate and allow access to different resources based on whether a user is logged in or logged out based on whether a user has admin credentials and you could even go through some more complex logic if you wanted to by creating different types of middlewares i know it seems like we've already run a marathon just trying to get the passport local strategy implemented but again authentication user authentication is not an easy subject i think we kind of treat it as an easier subject because it's like okay there's only a few moving parts here it seems like on the surface but once you get into the implementation there are so many different things that you have to understand in order to debug and have a solid grasp around user authentication i want to take a minute to say congrats there's been a lot of content so far and you have finally implemented your first official you know user authentication scheme where you actually know what's going on behind the scenes you can walk away from this tutorial right now if you want to but there is a second part to all of this which is the jwt based authentication that i think is super super important to know and it's probably one of the more popular ways to do it as i mentioned in the first you know a few minutes of this video but as we saw with passport local strategy having all of these prerequisites we also have some prerequisites for implementing a jwt authentication strategy in this section we're going to be tackling one of those prerequisites which is public key cryptography now i will make the disclaimer that to implement the passport jwt strategy or a jwt strategy in general you don't need public key cryptography in reality you could very well just use a symmetric cryptography scheme which is basically where you just make a long secret string and store that in an environment variable and then use that to you know authenticate through jwt now i chose public key cryptography over something like you know symmetric secrets because of a couple reasons number one i think it's really cool um public key or asymmetric cryptography is a really fascinating subject and it's also kind of the basis of bitcoin in a lot of those cryptocurrency systems so not only are you getting an education on user authentication but you're getting a basic education on how cryptocurrencies work as well and the second reason is this is arguably more robust of a solution than a basic secret key but in all reality if you're still watching this course then you're probably the type of person that would be interested in these extra little details so let's go ahead and dive into a basic introduction to public key cryptography this is a widespread topic public key cryptography and cryptography in general can be used for several different things whether you're talking about user authentication cryptocurrency or even just secure transport over https so i'm going to in this video be talking about what is public key cryptography and how does it work from both a conceptual and practical level so we're going to walk through the basics of you know conceptually how it works but we're also going to look at some code and see it in action before i get into what public key cryptography is we need to distinguish between two terms so that would be asymmetric and symmetric cryptography so public key cryptography what you see on the screen is a form of asymmetric cryptography because you have a public and a private key associated with it now a more basic form in what is used for tls or transport secure layer or whatever i think that's what it is otherwise the protocol that we use to transport data securely over an insecure internet channel that is going to be symmetric cryptography and is identified by a single key so a great way to think about this is maybe in a classroom setting so say you're sitting in a classroom and you want to pass a secure note to some of you know one of your friends across the room but you want to make sure that if the teacher intercepts that message they can't read it so what you would do is before class you're going to connect with your friend or friends that will be basically interchanging notes and you need to come up with a secret key so you might just come up with a real simple secret key and that key is going to be okay we're going to take every letter in the message and we're going to increment it by two so an a becomes a c and then to decrypt it you just have to take that c and bring it down two letters to be an a so now that the people that are interchanging messages know what the secret key or the cipher algorithm is they can easily read what the teacher thinks is gibberish when the notes are passed so to encrypt the data one student is going to basically you know write something down write the message that they want and then they're going to transpose it using the cipher algorithm so once again an a becomes a c a b becomes a d and so forth then they'll have someone you know walk that note across the class or pass it from desk to desk and we'll say that the teacher intercepts it the teacher cannot figure out what the note says it just looks like gibberish but the student on the other end could have decrypted that message by using that secret cipher so that is what we call symmetric cryptography and obviously we need to protect that secret now this is again used in transporting messages over the internet it's also used a lot in web application development you'll commonly see something called a secret key and that is what you'll be using to encrypt some sort of data now on the other side of things we have public key or asymmetric cryptography which is a little bit more complicated and involves a private and a public key pair so these private and public key pairs are mathematically linked as we'll see a little bit later in this video but the basic gist of it is if you have a public key you can give this to anyone as long as you keep the private key secret and then we can do two things with that public private key pair the first use case is going to be exactly what we just talked about with encrypting some sort of data so you might think of this the way that i like to think of it is a padlock and a key so basically i mean this is kind of a contrived example but basically think about maybe we're sitting in that same classroom and we have some sort of lock box and so one student is going to write a note which is just going to be in plain text and they're going to put the note in the lock box so what they'll do now is they will close the lock box and lock it with a padlock so that padlock before class was actually given to the student by another student who actually owns the key to the padlock so just to level set here the student that's writing the message has the public key of the other student who will eventually receive that message and decrypt it with the private key that corresponds to that public key so in other words student writes the message puts it in the box locks it with the other students public key then we send the box across the room we'll say the teacher intercepts it tries to open it but of course they don't have the private key that corresponds to that padlock or just the physical key that will unlock it so they can't unlock it can't see the message but if it gets to the student who does have that private key they can just unlock the padlock open the box and see the message so that is your first use case now the second use case is a little more complicated and we're not going to be able to understand it in the form of the classroom setting we're going to have to get into a little bit more complicated math but that second use case is called a digital signature or identity verification and this comes in handy when we're talking about user authentication and is pretty much the entire reason for me making this video so again if you're following along the passport.js user authentication series what you're going to want to really focus on in this video is that second use case or identity verification as you'll see to use these two use cases all we're going to do is change which key we are encrypting and decrypting with so to encrypt some sort of data but not protect an identity we're going to encrypt with the public key and decrypt with the private key as with the padlock and key in the classroom now the second use case we're just going to flip that we're going to encrypt with the private key and decrypt decrypt with the public key now in order to understand this we have to understand what a trapdoor function is and this comes in several different forms but in the case of public key cryptography or asymmetric cryptography we're talking about elliptic curve multiplication we'll get to that in one second but first let's just generally understand what a trapdoor function is so basically what a trapdoor function is is a one-way function that takes some pretty big piece of data and compresses it into a deterministic small piece of data outcome so in other words we can have an infinitely large piece of data we could have let's say something as simple as what you see on the screen right now or we could have something as big as maybe an entire book and what we can do is we can take that infinitely large or small data and put it through what we call a trap door function in this case we're using a sha 256 hash function and that will always create a deterministic outcome so it's going to be the same length i think it's i don't remember off the top of my head exactly how many bytes this is but it's a hexadecimal representation of the data on the left so if we were to come to an online sha 256 hash calculator i've pasted in that exact value in json string form and we get out this hash value and so anytime we put this particular data into this sha-256 hash function we're going to get the same exact output every single time so it is deterministic you can try it for yourself now we also have to know about this that we cannot go backwards so from this data on the right there's no possible way that we can derive what the original data was in the first place even though we know that we're using the sha-256 hash function we know that that's only one way you can't go the other way the last important thing to recognize about this is we have an infinite number space essentially now it's obviously not actually infinite but there are so many different combinations that the sha-256 hash function can produce that the chances of us having two different pieces of data that come to the same hash value is essentially impossible now there's plenty of stack overflow questions on this and you can read up on them on your own time but basically the probability of this guarantees that we're always going to get a unique hash value what we're interested in when it comes to public key cryptography or asymmetric cryptography is a one-way function or trapdoor function called elliptic curve multiplication now it's not actually multiplication it's a cryptographic function and basically all we need to know about this is that it mathematically links the private and public key so in other words using the using the private key we can derive the public key but having the public key we can never get back to that private key so in other words we can share the public key with anyone in the world and they'll never be able to figure out what private key corresponds to that public key this again is useful for those two use cases of either protecting some sort of data or verifying an identity we'll see a little bit more how this works when we actually get into the code but first let's kind of take a quick glance at how elliptic curve multiplication works so on the right you'll see the elliptic curve graph which is useful to us because given any point on kind of the on this graph we can take the tangent of that point and get to another point on the graph so say we're right here on the graph well this curve extends infinitely so we can just take the tangent all the way up to that curve so let's go to the next slide and first start out with what we call the generator point now the generator point is an arbitrary random value or coordinate that we will always start with now this point in many cases is going to be a fixed point that we use for a large private key i guess you could say number space so we always start with the same generator point but then the variable in the quick equation is the private key and we take that private key and we multiply the generator point by the value of the private key so again the private key is some infinitely well not infinitely but it's some small or large value and so we can just like we can take g times two and g times three we can also to do g times you know 10 trillion or whatever the total value of that private key is now you might ask how are we going to multiply g that doesn't make any sense this is a graph and how are we going to actually do multiplication well the way that that works in elliptic curve multiplication is by drawing tangents as we talked about so you start with the generator point and say that your private keys value is two now obviously it's never going to be two it's going to be a much much larger number and we're going to do this process many more times but essentially what's happening is we start with g we draw the tangent to that point on the curve which the tangent intersects this other point on the curve then from that other point we say okay what is the opposite side of the curve so we draw this completely vertical dotted line to get to this last point on the curve and that is essentially the multiplication value of our operation so g times 2 is going to equal this coordinate down here at the bottom so you can see how this is kind of it's not exactly the multiplication that we're used to but essentially what is happening is we start with this arbitrary generator point we multiply or we go through this process however many times the public or the private key value is and eventually we will reach a certain point on the elliptic curve and that is going to represent our public key now we cannot get back to the private key based on the public key coordinate but what we can do is we can derive that the private key that may be signed a message corresponds to the public key so if we so in other words what you need to understand is that using the complex math the elliptic curve cryptography does we can actually verify that a public key corresponds to a given private key mathematically without revealing the private key to the person trying to verify it so in other words we can decrypt a message using a public key you'll see how this applies a little bit later in the video just to recap before we get into the actual code if we want to do data encryption we're going to encrypt with the public key and decrypt with the private key if we want to do identity verification or a digital signature we are going to take the message that we want to sign and we are going to essentially sign it with our private key and then some random party you know some receiver of the message is going to have somewhere the public key that corresponds to the private key and using that public key as we just talked about we can use that elliptic curve algorithm to verify that yes indeed the person who signed it has the private key that corresponds to that public key okay so let's take a look at the actual code that will create this private and public key pair now there's of course command line utilities that you can use to do this but i wanted to kind of write it out so that we can explain it and understand it a little bit better let's go to vs code real quick and create a new file we're just going to call this create keypair.js we'll open up this file and i'm going to paste in some code that i already wrote so let's walk through this code really quick we're using the built-in nodejs crypto library and then the built-in node.js file system so that we can output the keys in this directory and you'll see what's happening is we have a single function that will generate a key pair all it's doing is using the crypto library to generate the private and public key using that elliptic curve multiplication under the hood and then we're going to write that private and public key to separate dot pem files in the current directory so you'll see that here is where the magic is actually happening and then down here is where we're taking those values and writing them to the files so you can see that we're using the rsa algorithm to generate the keys that's a pretty standard algorithm to use and then these you can just go ahead and look at them on your own if you want to pause the video to see what they represent but basically this is all the math that we just talked about and when we run this script by saying node create key pair it's going to finish and then you'll see on the left we have both a private key and a public key in other words this private key is something that we want to keep to ourself not share with anyone and the public key can be shared with absolutely anyone with full confidence that they will never be able to figure out what this private key is all right now that we have our private and public key let's go ahead and use that in both of those two use cases that we talked about earlier so to do this just remember we have the private key and public key saved in this current working directory so i'm going to close them i'm going to close the create key pair and then i'm going to create a new file called encrypt.js and in this new file we're going to write an encryption formula where we take some sort of data and we encrypt the data and we protect that data so i'll paste in the code you're going to see we require the crypto library again and then i've got a single function that's going to take a public key and a message as an argument so again if we want to protect data but not an identity we encrypt with the public key and decrypt with the private key so what this file is going to do is it's going to take the message that we give it it's going to create a node buffer with utf-8 formatting from that message and then it's going to pass that buffer into the built-in public key encrypt function that the node crypto library provides us with and then what we're going to do is we're going to export this function so that we can import it into another module so now that we have this we can save it and then create one more file called main.js where we're going to do a lot of the work let's go ahead and open up main.js and copy in some code that i already wrote a little bit earlier so again we're using the file system and then we're also importing this file right here that we just wrote so by importing this we have access to the encrypt with public key function and so what we're going to do in the main file is we're going to first get access to the public key that we created and stored in that pem file in the current working directory so we just use the file system to do that and then what we're going to do is create an encrypted message and store it in the encrypted message variable so you'll see that we're going to use the function that we defined in this other module we're going to pass in the public key that we got from the file system that we created earlier and here is our super secret message that we don't want anyone to be able to decrypt over a public channel so once we do that we can basically console log the encrypted message as a string and you'll see when i save and run this file that in the terminal you'll see some gibberish that we cannot decrypt so node main.js and of course we see a bunch of gibberish this means absolutely nothing to us and there's no chance that we figure out what this super secret message was based on this data so in other words this right here is what you're going to transport over any sort of insecure transport layer so to decrypt this we can do that with our private key so let's take a moment to see how that works we'll clear the terminal and create another file called decrypt dot js and when we open that up we can paste in a similar function to the encrypt file so we're going to require the node crypto library define a single function where we decrypt with the private key and then all this will take is our encrypted message and the private key and then it will use the built-in node crypto library private decrypt function so we're going to export this function so that we can import it in another module save it and then we're going to use the main module to actually decrypt this okay so you're going to have to use your imagination a little bit because we're both encrypting and decrypting in the same file but hopefully this will make a little bit of sense so at the top part of the file we have encrypted our super secret message right here at the bottom part we are going to import our private key and then we're going to use the decrypt function and we're passing that encrypted message into the decrypt function and finally we'll take that decrypted message and convert it to a string and print it to the console so what we should expect with this file now is that in the console we're going to get that gibberish message that is encrypted and then finally we will have the decrypted message which should say super secret message so let's run that real quick we'll say oop come down to the terminal we'll say node main.js and we have a problem so let's see what the problem is decrypt is not defined because i did not import it so let me import that real quick now that we've imported it we can use the function let's try one more time so we got the gibberish up top and then we finally got the decrypted message at the bottom so that is just a basic way that you can understand how we use private and public key pairs to protect data over an insecure transport layer in order to see how digital signatures work we're going to have to add a few things to our encrypt and decrypt modules because remember we are going to encrypt and decrypt with different keys based on which use case we want to use so let me do in the encrypt encrypt function or module i'm going to add another function called encrypt with private key so we can encrypt with the public key in case of data protection or we can encrypt with private key in case of a digital signature so let's go ahead and export that from this module real quick so encrypt with private key so now we have a module called encrypt which we can do both encryption with the private or the public key likewise we need to do this in the decrypt module so let me just highlight this whole part paste it in we've got an extra import here and we've got our function decrypt with public key so now that we have those components we can see how a digital signature actually works but mind you a digital signature is a little bit different than protecting data we're going to have to go through just a little bit extra work to do this because this is a little bit more complicated i'm actually going to make separate files for the steps of the process so with the digital signature we have some sort of data that we want to put our signature on so just think of it like a legal document you have the document itself with the data and you want to sign it and you want to make sure that the receiver of that data is assured that both the data that was on the document has not been tampered with we don't want someone intercepting it and changing some of the legal proceedings on that paper and we also want to make sure that the person we think signed it actually did sign it so that's step one we need to sign the message step two is actually verifying it as i just described so for step one let me go ahead and close all of these files you know what's you know what is in them so we will create a sign message dot js file and in this file let's go ahead and import some different modules so let me walk you through what's actually happening here starting from the top we have the node crypto library pretty familiar we also have the file system and then we have the encrypts and decrypt modules that we created ourselves now the last thing is this hash function and this is a sha 256 hash we talked about this a little bit earlier and it is a trapdoor function that takes a pretty much infinitely large or small piece of data and you put that data through the hash function and the output of that hash function is going to be every single time you do it it's going to be the same exact value and that value is going to be small enough that we can kind of transport to different places it's always going to be 64 characters long which each character is four bits so you have 260 or 256 bit value that is always going to come out of that function no matter how big or small the data you put into it finally at the bottom you'll see that i have a piece of data this is going to be the data that we're going to sign now you'll see that i've got my first and last name and then in the social security number field we're never going to put that because remember this second use case of signing some sort of data does not protect the data itself if someone intercepted this data on an insecure channel they would be able to read everything that is contained in it so we never want to put any sort of confidential information in data that we are digitally signing all right so the first thing that we need to do is we need to take this data right here since it's pretty large and we need to compress it down into that sha-256 hash so to do that deleted it to do that i'm going to paste in some code that i wrote earlier and what this code is going to do is first store the json string value of this data right here and it's going to store that in a variable and what we're going to do is we're going to use that node crypto library hash function and we're going to hash the data that i just put in string form then we're going to convert that into hexadecimal format and this is important because the format that we're passing values between function in is actually really important when we're using the crypto library we are now ready to actually sign this data so let's paste in some more code first we're going to get access to the private key that we created earlier in second we are going to store the signed message in a variable we're going to use the encrypt with private key function that we created using the node built in crypto library we're going to pass in the the sender private key so in this case i am the sender of this data and i own a private key that i'm going to sign this message with so i will sign the data with my private key and this data is going to be in the form of the hash data so we're not just going to sign this big data object we're going to sign the hashed version of that data now the last thing that we have to do is kind of that extra step that i was talking about so if you just sent this signed message to someone they're not going to be able to do anything with it not only do we have to verify that nobody has tampered with our legal documents so to speak we also need to verify that the person that says they signed it actually did sign it to do that we need to provide the receiver of this data with a few additional pieces of information so those pieces of information is number one which hash function we used to hash the data number two we have to actually give them the original data so that they can take the hash function take the hash of it and then they can eventually take the signature that we provide them with and match it up with that hash data to make sure that the that i actually signed the data in the first place so let's go ahead and see what that looks like we'll go ahead and create a final piece of data so we'll say package of data to send to be very explicit and we'll paste in this data object so we've got an algorithm so this tells the receiver of data i want you to use the sha 256 algorithm and what i want you to put in that algorithm is the original data that we created so you'll see that the original data is my data which is the original object of data that we will use and then of course we have the signed and encrypted data which we assign to the signed message right here so with this information a receiver of this data can verify using my public key that not only was the data not tampered with but i also signed it last let's go ahead and export this package of data so module dot exports dot data or let's just call it the same thing that we called it here package of data to send equals package of data to send so we can access this from another file to do this we're going to create another file called verify identity.js we'll open up that file and we'll put our imports in there so we need the crypto library we need that decrypt module that we had created on our own and then we need to import the data that we just exported from that other module so this is everything that we need to verify this message now we also need to bring in the public key of the sender so this will be made publicly available and we'll say that you know i sent this data in the first place but my friend jim whatever is going to be verifying it so jim will need my public key to do this which again public key is public and anyone can see it you can feel confident that they're never going to be able to figure out what the private key was and one thing you'll notice that i required this in but i need to grab the variable that we exported so require this module and the variable so our received data is equal to this object right here in the sign message file next we need to actually take our own hash of the data that we were provided so to do that we know that we're using the sha-256 hash and so we can use that hash function to hash the original data i'll paste this in here and you'll see that our hash function is going to be the built-in node hash function and it's going to be the algorithm that was in that data package so i know this is a little confusing but this line right here in the verify identity file is the same as this import right up here so where we said create hash sha 256 we're also creating a hash and we're just using that algorithm that we've received in the data package like i said we also need the public key of the sender so we'll go ahead and get that in the public key variable the next step to doing this is we have to take that data that was signed and decrypt it so let's think about what this is actually doing i'm going to paste in the code and we're going to use our decrypt module we're going to pass in the public key right here this is the public key of the sender and then we're going to take the the data that we received and we're going to pass in the signed and encrypted data so if we come over back to the sign message let's figure out what this was so our signed and encrypted data was our signed message which basically if we decrypt that message what it's going to give us is the hash value that we derived from this original data so what we're going to get in this variable right here the decrypted message is simply a hash value so in order to verify that we can then take our own hash of the data that was provided in this object right here so this is the original data and if we take a hash of that and compare it to the decrypted message here they should match and if they do match we can know that not only was the data not tampered with but it was also signed by the person who said that they signed it one extra step we've got to do is we've got to turn that decrypted message into a string value to pass it into our function that's just a formatting thing finally we say we want to look at the hash of the original so we're going to actually take the hash of the data that was passed to us in that data package and then we're going to turn that into a hex value to verify it we'll just do a basic if then statement so we'll say if the hash of original hex so basically our own so this is the receiver of data jim is doing this he's taking a hash using the designated hash formula and just turning it into a hexadecimal value so that we are comparing apples to apples and then we're taking the decrypted message hex which is basically what came with that is what we decrypted in comparing them so if it is the same then we're going to say success the data has not been tampered with and the sender is valid so let's see if this works let's go down to our console and run node verify identity and you'll see that it says success data hasn't been tampered with we have the right sender so hopefully that makes sense that is the second use case of public key or asymmetric cryptography and is called a digital signature it's a very common way to verify data and identities and you'll see if you are following the passport.js series that this video is kind of associated with you'll see exactly how that works when we actually are authenticating users now just as a consolation for this video what we just did over the last few minutes when we were signing and verifying a message is the same exact process that is used with json web tokens so you might say wait a second there might be a better way to transport this package of data over the internet and you are right there is indeed a better way to do this if we were to send this package of data it's going to actually be a pretty large piece of data and it's going to slow all of our web searches down especially if we're using it for some sort of authentication so naturally the easier way to do this is to represent this piece of data in a much smaller form just like we took the original data and we took a hash of it to make it smaller and more transportable we can also do that with the data package that is sent to the receiver of data and is used to verify the original data let's jump into the browser real quick and what i have pulled up is jwt dot io which has a really simple jwt visualizer per se now don't focus on what is going on here because i have a separate video on that but just recognize the structure of what's going on so on the left this is our entire jwt token and you can see that it is pretty short and it would be very easy to transport over the internet in a quick and efficient manner but if we decode this jwt it has the same critical information that we saw when we were signing and verifying an identity in our code earlier so first we have the algorithm which is represented by this reg string and so this will tell us exactly what sha or sha 256 hash algorithm that we have to use to decrypt the data then we also have a payload which is represented by this purple string and you can see i guess i deleted something here but you can see that it has all of the information that we would need to include in that payload of data so this you could consider that legal document that we are signing and then finally at the bottom you have the actual signature and the signature is going to include um you'll see the public and private key here but this is actually just going to be the signature that we wrote in the code earlier and we can verify it with a public key all right now that you have a basic understanding of public key cryptography we can move on to understanding what is a json web token now i could of course go through a basic example and just show you the pieces and all that stuff but i want to take it even further as i promised this is you know hopefully one of the most detailed user authentication courses that you've ever taken and in that light i want to actually derive and sign our own implementation of a json web token using some of the internal node.js libraries the questions that i'm going to answer in this video is first what is a json web token we will then go into answering the question of how do we derive a json web token like what are the pieces of it and how would we actually create one using code and then finally i'll give you a little bit of context as to how it applies to user authentication among other use cases we'll start the video off by looking at the jwt or json web token spec on the internet engineering task force it is going let me switch to google chrome real quick you'll see that they have a write up on jwt's and the specification for using them we'll come back to this in a minute to look at a few things but um this is a very well established type of token per se i guess you could call it a token that we use to transport some sort of data on the web now something a little bit more friendly that we can look at is a website called jwt dot io and right here i am looking at the example jwt and we're going to be able to visualize what is going on a lot easier once we kind of understand what the jwt is we'll actually go into writing some code to kind of replicate this example right here so to understand jwt it's pretty simple there are three parts you have the header the payload and the signature now the header and the payload pretty easy to understand the signature not so much because there's actually multiple types of signatures that you can do and therefore it adds a little bit of complexity on top of that a signature is a digital signature and it has to do with public key cryptography or just symmetric cryptography depending on which algorithm you're using so it requires a little bit of background knowledge which is why i recommended watching that video that i had created on public key cryptography before this one now you'll see in the algorithm field up top we can kind of scroll through all the different choices that we have for writing a digital signature on a jwt but in our case since i had you watch the public key cryptography video we're going to do the rs 256 algorithm which is basically as you'll learn more when we get into the code is telling us two things so number one we're going to use rsa private and public keys that standard and then number two we're going to use the sha 256 hashing function to actually take a hash of the header and payload data i know that's a mouthful we haven't learned anything yet so just hold on to that knowledge in the back of your head we'll come back to it and understand it in a lot greater detail in a few minutes let's start out by getting a basic understanding of what a json web token is so i mentioned that it was made of three parts you have the header the payload and the signature and these are highlighted on the page here in the different colors and they are separated by a single period so the first part in red is the header then you have the pink part which is the payload and finally this turquoise part is the actual digital signature now what you're looking at right here is base64 url encoding and i'm not going to get super into it but just a few fun facts about base64 url encoding it's a encoding spec that basically aims to standardize character sets and it's derived from the base64 encoding which was originally created well before you know my time of learning to code but from what i understand the idea there was previously before the utf-8 standard where we had you know standardized character sets there was debates over whether you know there should be four bits or five bits or seven bits or eight bits within a single byte of data and before that was standardized as eight bits per byte there was varying use cases and different you know protocols and applications would use different number of bits in a byte and so therefore you might have an application that actually cuts off the last two bits of data so what base64 was aiming to do was basically add this thing called padding into the data and so it makes it so that there's no chance that any of the data is going to get lost in transport and then the base 64 url encoding is just one extra step because there were some characters within the base64 encoding that are not exactly url friendly or file name friendly so converting base64 to base64 url just makes it safe to transport over the internet and we also know that this format in general is not going to lose any data which is obviously very important when we're talking about user authentication which is a very common use case for jwts i know that was a bit of a long-winded explanation of an encoding um not so interesting but as we actually derive this jwt with code you're going to see that we're kind of constantly having to shift between the different encodings and it's going to become a little bit more important later all right now that you know what you're looking at here on the left let's talk a little more conceptually what we're seeing here on the right side so on the right side all we've done is we've taken these base64 url encoded characters and we've decoded them into json objects and in the header you'll see that we just have a couple things we have an algorithm and a type and this is pretty self-explanatory but when you're transporting json web tokens over the web it's not always the case that the receiver of the json web token is going to know you know anything about the json web token to start with so in the header the sender of the json web token or the issuer is going to identify which algorithm they use to create the digital signature and then of course we say that the type of token is a jwt because there's actually other types of token tokens that we can use here aside from just json web tokens so we have again chosen the rs 256 algorithm which says we're using public key cryptography for the digital signature along with the sha-256 hashing function and what we're going to do is well actually before i get into this let's cover what the payload is then we'll get into that signature so the payload is basically going to be metadata about some entity and in most cases it's going to be about a user because jwts are commonly used for user authentication so in this payload you're not going to see any sort of credentials if you see credentials in a jwt payload then you know that the developer has done something wrong because you should never ever put credentials or sensitive information in the payload it's publicly available anyone could decode this jwt just using a simple base64 url decoding algorithm so what this data gives us is just general information about the user so you'll see the sub or subject is going to tell us who the user is in many cases you'll see some sort of database id put in here so that when an application decodes the jwt they see okay here's the sub it is this id let me look up this id in my user table and retreat retrieve the full user object so that's what the sub is um name obviously just the name admin just another metadata property and then iat is issued at so it gives you the time stamp of when the jwt was issued now we also have additional um what they call claims that's kind of the proper term for these pieces of data we have additional um claims that we can define and if you go over to the specification for jwts you have all this information but down here at the bottom or somewhere in the middle we have the registered claim names so these are registered it says the following claim names are registered in the iana json web token claims registry established by section 10.1 so in other words these are kind of the official claims that you'll be using and if you wanted to issue jwbts that would be interpreted by various applications you would want to use these standard claims so that everyone knows exactly what they mean so let's just go through the most common ones and then there's a few others at the bottom you can look through on your own so first is the issuer claim this is going to identify the issuer of the jwt now in our case we probably don't need this because we are both issuing and verifying a jwt within the same application but in many cases for more complex architectures you'll see a certificate authority who is actually being it's the certificate authority acts as the third party authority that is trusted to issue jwt tokens and that is literally all they do so we have we basically can establish a centralized authority that everyone trusts and that centralized authority will sign the jwts with their private key and because they sign it with their private key they'll say okay here's our public key and anyone in the world can say okay i trust that institution and i'm going to verify this jwt with their public key if it matches i know that this jwt was issued by a trusted authority so that's kind of where you'll see the issuer claim the subject claim we already covered the audience claim is going to generally be the resource that will accept this jwt so in other words um if the jwt is only intended to be used with a specific application um it would probably list some sort of url or base url that will identify which server the jwt is valid for so in other words if google issued a jwt token they might put in the audience claim www.google.com and if the jwt is attempted if if you attempt to use the jwt in a different context other than google.com it's going to be rejected then finally we have the expiration claim which basically tells you when or what point in time this jwt token is no longer valid there are additional claims that you can put in here we saw the iat issued at claim but you can also and this is important you can also make up your own claims this by no means has to be standardized you can put whatever metadata that you want in the payload and last but not least we have the signature at the bottom we've already kind of touched on it i talked a lot about how this actually works from a cryptography perspective in that video that i asked you to watch before this one again link is in the description for that but anyways i think it would be helpful to go through kind of a conversation between the server and the client to understand how this jwt is working in real life so i've put together a basic little representation of this and what we have here is what i kind of perceive as the conversation that the server and the client would have if they could talk to each other in human terms of course so the server just think of this as any application we're kind of removing the idea of certificate authorities from this basic equation we're just going to assume that the server will just say it's an expressjs application is both issuing and verifying the jwt tokens so we don't have that third party certificate authority in this equation so what's going to happen is our client or just basically our user someone sitting behind a computer who is visiting our application on the web is going to go to the login page and say hey server i want to log in to your application here's my username and my password then the server gets that information in the form of a post request and it's going to say okay let me check on that i want to go through my verification algorithm and look you up in my database to make sure that you exist and you entered valid credentials we'll assume that the user did so the server says okay your credentials look great i'm going to sign a jwt token or jwt with my private key that only i know about so the server is the only entity that has any knowledge of that private key they're going to sign it and send back the jwt in the response body so then the client or the user basically this this doesn't actually have any user interaction it's invisible to the actual person behind the computer but the browser or the frontend application is going to receive the the response and say hey thanks for the jwt i'll keep this stored in my browser's local storage until maybe it expires so then the client is going to once they're logged in they're going to want to do something so maybe this client wants to go edit their profile so they'll type in the url of the profile just say some site.com this is just an arbitrary value and then they're going to need to attach that jwt token or i keep saying jwt token but it's json web token to the http header that's called the authorization header and so in the authorization header is where that's going to be stored the server is going to receive that jwt in the request body and then we're going to say okay i just talked to you we're familiar but i still need to verify that jwt because i don't know if in the time that you chose to visit the profile did someone tamper with it so we're going to take the jwt and now the server says okay i signed it with my private key but now i'm going to take my public key that everyone knows about but i don't care because it doesn't actually matter i'm going to take that public key and verify the signature on that jwt and the server says okay that signature is indeed valid i know that you know you are actually you and the claims made on the body of this jwt are valid let me go ahead and look you up in the database load your user profile and give you the information required to actually edit that user profile so that is the basics of how a jwt works i'm going to in a few minutes go through the code for deriving a jwt but i will also mention again this video was intended to be kind of part of my node.js passport.js video series which the playlist is listed in the description below if you wanted to know more about what we just talked about how this actually works in practice written in code say for an angular application go ahead and follow that series through the end use the passport jwt authentication strategy and you'll see exactly how this works in practice but for now we're going to jump into the code editor and actually see this process written out how we issue a jwt and then how we verify that jwt just using the built-in nodejs crypto library to start off with we're going to go through this part where we issue a jwt to keep it as simple as possible i'm going to take the example off of jwt.io so if you visit this you should see the same thing and i'm going to actually be showing you how we get to this jwt how we actually issue this one and then how we verify it using the public and private key so you should be able to verify how this works by just coming to this site and you can actually follow along with the node.js crypto library so i'm going to go ahead and just copy this entire token again this is in base64 url format or encoding so i'm going to copy that and then we're going to come into the code editor and paste it in here so i first need to create a file so let's just say issue jwt.js and you can see that on the left here i've already pasted in the private and public key those came from that jwt.io website alright so i've copied in the key right here let me just put this as a string and store it in some sort of variable so we'll say const jwt equals that so this is the exact jwt that we saw from that example website now in order to properly do this we need one npm library and it's called base64 url so i've already installed it but you'll come down here to your terminal and install base64 url to follow along with this so i'm going to go ahead and require that in real quick so we'll say base 64 url and now we can take this jwt right here and convert it into something that we can actually work with we now need to split up this jwt into its parts which if you remember is designated or delimited by this period so we can do that using some simple javascript so we'll say jwt parts equals jwt dot split and we'll specify that period so now if we were to console.log the jwt parts we should have an array of those three parts so let me go ahead and try that real quick and you can see that we have an array and the array contains the three different pieces of that jwt token again these are still in base64 url encoding let's go ahead and split these into variables so i've just written this code already we basically say header in base64 url url format is going to be the first one so in our array right here we're just grabbing that piece and then so on and so forth with the remaining two now what we have to do is we have to actually take this base64 url format and convert it to something else now that we have this in pieces we can decode this with the base64 url decoder the npm module we included up here and we can see the actual json objects that these represent so let me put those in variables real quick so we have the decoded header payload and signature and we're just using that base64 library and using the decode method and we're passing in the base64 url pieces and then finally we can console.log those to the terminal and you can see what they look like decoded so let's go ahead and console.log those we're just taking these three variables here and logging them save the file let's give us some space in the terminal here and let's run this again so you're going to see the first part is the same thing that we saw on google or on the in the browser at jwt.io and the second part also so these match perfectly as we would expect and then we have a bunch of gibberish at the bottom and the reason being is because we haven't actually um decrypted the signature yet so once we decrypt the signature then it will be in a format that we can understand a little bit better now that you've seen this decoded i'm going to actually comment all of this out for a second because we don't need this we're going to actually derive this jwt from scratch so commenting that out for a second we'll just space it down to the bottom and what we're going to do is actually create this from scratch by first creating the javascript objects that we want to put in the header and the payload so you can see that these are the exact same header and payload objects that we printed in json format below now obviously these are in javascript format so we will need to convert them into json format by saying using the json.stringify method so let's do that right now i pasted in the json.stringify method and stored these two objects as json strings in these two variables the next thing that we have to do because right now these are just in json format we need to actually convert that json format into the base64 url so to do that we'll use this base64 url library and we'll just put it through the basic function and convert it so here we go copy this in i'm just copying code that i wrote before to speed things up but anyways we have new variables hopefully these are labeled appropriately for you but we have a base64 url header and payload all we've done and we actually need to change this a little bit so we're going to just use our import here base64 url and the basic function that comes with that library is just a function to convert any sort of object into the base64 url format so these two variables store the correct format for our header and our payload now we have to actually sign and issue the jwt but first let's go ahead and check this we're just going to console log these two values to make sure that we have actually converted these original javascript objects correctly so let's go ahead and clear the terminal give us some space and run this again and you'll see these two values which we can actually check from the commented out code so here's our original jwt that we just took from the website and posted right in there and you'll see that this first value matches the first value of there and then the second one if you wanted to go out there and confirm that it also matches so we've got what we need again the last thing we have to do is actually take some sort of hash of these two pieces of data and then sign that hash and put that in the signature in order to sign this we need to import a few more libraries so at the top i've imported the built-in node.js crypto library and then from the crypto library we can also implement the algorithm that we're using for this jwt so this is going to allow us to sign the jwt using this specific algorithm and then we need the file system from the node.js framework so that we can access the private and public key that we have saved in this current directory now that we have our imports let's come down here get rid of these console logs and we're going to create the signature so the first step is to use this signature function and we want to write some sort of data into it so right here we're just passing in the header and the payload separated by this period and this is going to be the data that is actually hashed using the sha 256 hashing function this is all kind of done within this node crypto library but we're going to hash this data and then we're going to sign the hash so we've loaded the data in here the last thing that we have to do is load our private key which we're going to be signing it with and then use the signature function sign method to actually sign the jwt here is the code to do that copy it in first we need to load our private key that's literally just loading this private key pen file and i actually need to change the name for this to work correctly so private key dot pem and it's important to put this in utf-8 encoding and then we are going to convert this is kind of an important part we are going to sign this data which is going to give us a base64 encoded signature so then to actually derive the jwt we're going to have to convert base64 to base64 url we can do that with this imported library right up here so i'll show you the code for that here's the code that we use to do that so we just basically take the signature that we got from the node crypto library and we convert it from base 64 to base64 url so now the signature should be in the same exact format that we were expecting earlier let's go ahead and verify that real quick so signature base64 url we'll print that out really quickly and you're going to see this value right here let's go ahead and just verify it real quick so here again is our jwt we need to come all the way out to the last piece of it and here we go there's the last piece and you can see that the first couple letters are matching up and if you were to go through all of it it's going to match to the character so right there we from scratch created a jwt token using the node.js crypto library now there is an easier way to do this and i will show you that in a few minutes but first we need to verify this jwt that we just issued since we already have a lot of the basics set up we're just going to uncomment some of this code to verify the signature so let me just make a comment for this first part probably should have just named this file jwt because we're doing both the issuance and the verification in the same file so here is the issuance part right here and then end of issuance and then here is the verification and we will go ahead and implement this now so when we verify at jwt we are basically receiving the jwt in the base64 url format in this case we just are going to use this one right here the one that we just created because we know that um it's exactly the same as that example online so to get the jwt parts we're going to uncomment that we will uncomment this part we don't need any of these things right here and i think we're set so now we can actually verify this jwt to do this we'll actually have to just create one more line in the imports and this is going to be the verify function from using the same exact algorithm so we've got the issue or the create jwt function and then the create verify or the verification function as the verifier of this jwt we have received the entire jwt right here we've split it into parts and now we have to actually do something with those parts so the first thing we'll do is we'll take the header and the payload and just like the signer of the or the issuer of the jwt did we're going to take the header and the payload and append them together separated or delimited by the period and since the the node.js crypto library only accepts base64 encoding we need to take the base64 url signature and convert it using the base64 url npm module to base64. so now that we have that we can finally i guess decrypt the signature so we're going to take our public key that corresponds to the issuer issuer's private key and we're going to decrypt the signature so the first thing we need to do is actually get the private or the public key in here so i'm going to just copy this line and use that we'll say public key and we just need public key dot pem so now that we've imported our public key that we're verifying with we are finally ready to verify this jwt so let's copy this in the signature is valid variable is basically going to run the node.js crypto library verify function that we imported right here so verify function dot verify we're going to pass in the public key that we imported from the file system we're going to pass in the jwt signature base64 format and then the most important part this will really trip you up it took me honestly hours to actually get this to work because i had not included the base64 format in the verify function so that's really important and once you've done that we should console.log the signature is valid and i think it returns a boolean whether it's valid or not so let's go ahead and try that really quickly node issue well it's not really issue jwt but bear with me we get first the signature that we were console logging right up here and then the signature is valid variable returns true so we have successfully verified this jwt and essentially we've gone through the whole process so we created the jwt from scratch and then we verified it from scratch now if you wanted you could use all the code that we just used in this example for your web applications to sign and verify jwt tokens but like i said earlier there is an easier way to do this and that easier way is using the json web token npm library and what this library is is basically an abstraction of the node.js crypto library and it gives you a little bit you know more options because in this example we were just using the rsa256 algorithm and we didn't even get into okay what if we use a different jwt algorithm so the json web token library is going to give you a lot of flexibility and it also kind of abstracts away all of the things all of these you know when we have to convert from base64 url to base64 you don't have to worry about doing that in this library so this would be the library that i would recommend using in any sort of web application where you're issuing and verifying jwts and in the next few minutes i will show you exactly how to use it to save us a little bit of time i've just copied in my implementation of the json web token library um if we wanted to accompl accomplish the same exact things that we did with the node crypto library now obviously since this is abstracted a little bit you're not going to get to see the little bits and pieces that are happening and you don't get to truly understand what is happening with the jwt but it does make your life a lot easier when you're actually coding so let me explain to you what's going on here the first thing you'll notice is i imported the json web token library i already installed it with npm install json web token so that is what that import represents we use the file system the node.js file system to grab the public key and the private key that we were using earlier so again this is the public key and private key from that example on jwt.io and then you'll notice this payload object is very similar we've seen it before because it's the exact same payload object but you might notice that you don't see the header and the reason being is that is one of the things that this library abstracts away all we have to do is provide the algorithm and the library creates the header on its own so you'll see in this next line we have a variable called the signed jwt which is a product of the json web token library sign method where all we have to do is pass in the payload object in javascript form so we don't have to do any of that json.stringify stuff and then convert it to base64 url none of that we can just pass in a javascript object then of course we pass in the private key that we want to actually sign it with as we know that's how jwts work and then finally in the options object we just have to give it the algorithm that we want to use and based on this algorithm the json web token library is going to figure out what the header needs to be so it will then combined that header and the payload just as we did with the node crypto library it's going to sign it with i actually think they use the node crypto library underneath the surface so they pretty much do exactly what we did earlier to sign this and then to verify it again just one simple line of code or a couple simple lines of code we just used the json web token verify method we passed it we pass in the signed jwt or this basically it's going to be received in the authorization http header for a web application so we take that jwt pass it into the verify function we use the public key that corresponds to the signer's private key in this case since we're doing the signing or the issuance and the verification it's just these two this key pair and then again we have to pass in the algorithms that it will accept in this case rs256 and then we have a callback function in the callback function if there's an error we know that the verification has gone wrong and either we have the wrong public key to verify this jwt with or the jwt was tampered with and we don't want to use it so let's go ahead and just verify that this works really quick so you can see it in action i will console.log the signed jwt value so let's just do that first really quickly and you'll see this value right here which if you were to match with the value online it's going to be the same exact thing so um you can do that on your own time but just trust me that is the same exact jwt and then here we can go into the callback function and let's say console dot log air and we should expect that we don't see any error whatsoever because we verified this successfully so we get null as the air as expected and then we can also console.log the payload which is the second argument that it returns and you should get the same payload that we had defined right up here except this was when we issued it and then this is when we signed it so you can see how this might work in an actual application you might have a post route that is going to verify credentials and then it will sign and return a jwt in the response and then you might have another couple routes that are like authenticated routes and you might have some sort of middleware like passport.js that is going to underneath the hood use this jwt.verify method and use the public key to verify the jwts that are being passed through the authorization headers couple hours later and we're finally ready for our second form of user authentication which is the passport jwt strategy i think this next section is going to be really rewarding for you because we're about to take all of those prerequisite lessons that we went through whether that be the express middleware overview or you know the basics of cryptography we're going to combine those together and put it into our user authentication strategy this one's going to be fun so let's jump in the first part of this series we went through the passport local strategy and in doing so we talked a lot about the inner workings of the passport framework and in this second part since it's a little bit more advanced i'm going to be skipping over those details so if you find yourself lost for example in the process of generating and validating a username and password in a database or maybe the verify callback for the passport middleware i would suggest going back to the first part of this series and specifically just watching the configuration video for the passport local strategy now before we start to code i want to go through the options that we have here when implementing a jwt authentication strategy so we're working with the passport jwt middleware strategy but we don't necessarily need to and this is going to be the most confusing part for someone looking for a solution on the internet because there are all sorts of ways that you can actually implement a jwt strategy in your application and because of that you'll have people who understand json web tokens pretty well and they'll have their own custom strategy working but they won't explain kind of how they got to that strategy and it leaves you the reader of the tutorial just thinking to yourself well what's the actual correct way to do this and in this video i've stuck with the passport jwt middleware not because it's a hundred percent necessary but because i think it's kind of grounded and it gives us a framework to start with and then we can kind of customize on the fringes as we see fit if we were trying to be very complex about this and probably the reason you would do this if is if you were maybe trying to write your own authentication framework or you're building your own authentication server or something that you have to do that's extremely custom the most complex thing that you could do is you'd use the node.js crypto library and then pair that with your own express middleware that work together to authenticate your users now i have no interest in doing this because there's a lot of code that you'd have to write to do that but given the fact that we actually went through the process of issuing and verifying jwts with the node.js crypto library you already have a pretty good head start if you did choose to use this now the somewhat complex method for authenticating users via jwt would be to use something like the json web token npm library which is going to give you a little bit more abstraction you have a lot less things to think about when you're actually issuing and verifying the jwts but you're still left with writing your own custom middleware for your express application so that leads us to the least complex method which is what we are going to do and that is to use the json web token npm library so it's going to be really simple to issue and verify the jwts and then we'll use the already built framework passport.js and then plug in the passport jwt strategy into that framework so we have our middleware written for us but you don't need this like i said there's a lot of different ways that you can do jwt authentication the reason we're going to go with the passport jwt strategy is because it kind of just takes takes care of some of the tedious things like say air handling or extracting the token from the authorization http header like all of those things you have to write your own code for which is also going to be airprone and you've got to test it so we would prefer to kind of offload that to a framework that's already been tested and used by a lot of different use cases so that's kind of why we're starting with the passport jwt strategy but wanted to lay that out for you the last thing that i want to go through before we get into this is the basic conceptual flow of how jwt authentication is going to work now this slide right here assumes that you understand the issuance and verification process of a jwt which again was in that prerequisite video in this playlist but anyways what happens is a user is going to log into web app so we'll assume that they're already registered um they're already stored in the database our application is going to go through the basic password verification process i talked about that in the session based authentication or the passport local video but basically all we're doing is we're taking the the username that the user is going to log in with we look up that user in the database and then in the database we have a salt and a hash stored for that user then we're going to use some of the um node.js crypto library methods to actually take the plain text password that the user just passed to us and compare it against the salt in the hash that were stored for that user record in the database if the user has validated correctly based on our logic then we are going to use we'll say the json web token npm library to issue them a new jwt token now this jwt token has information about that user as well as a signature from the server itself so one of those pieces of information is probably going to be the database id of the user so then the user client which is usually a browser is going to store that jwt so back up just a second the server issues the jwt and sends it in the response body of the http request then the user client receives that http request and stores the jwt that it received there in local storage or maybe even a cookie it doesn't exactly matter where you store it it just has to be persistent storage in the browser then on every single http request that requires some sort of authentication so maybe you're trying to access a protected api the user is going to or the user client is going to attach that jwt in most commonly but not always the authorization http header the important thing is that you put that jwt in the correct header that the server is expecting and the authorization header is just the most common that you'll probably see then the server looks for that jwt in the authorization header because you've coded it to do so and it's going to use the json web token library to verify the signature of the jwt if the signature is verified we know two things we know that the jwt has not been tampered with none of the data in it has been tampered with we know that it also came from the person that we expected it to come from so if the signature is valid the server then will decode the jwt which is in base64 url encoding so all we're doing is just taking that from base64 url to json format then we will read the um the payload which is going to have information about the user so we're going to probably go for the payload.subfield that's the most common place to find this information and it's where we're going to implement it in this video and we're going to grab from that field is going to be the database id for the user so then the server is going to take that id look up the user in the database and then now it has the full user object it can do whatever it wants with that user object in our case it's going to attach it to the um express request object and then we can use it within our routes and then finally once all that has happened the user is going to have access to the resource that they requested and our flow is complete that's the process if you ever find yourself confused as to what we're doing with the code later in this video in the next couple videos i suggest that you kind of keep this you know pause the video on this slide take a screenshot of it maybe even print it out so that you know exactly the the pseudo code steps that we are going through okay so the next thing that we'll do is come back to our code and what i have open is a github repository that you can download yourself and how i've structured it is we have two branches on this repository let me see if i have it open in the browser we can just visit it there there we go so here's the repository that we that we have i just finished it up a few minutes ago but basically we have two branches to work with so the first branch that we have is going to be master and this is what you're going to have is the default when you clone this and it's going to give you a basic starter skeleton for implementing the jwt authentication strategy as i talked about in other videos my goal here is not to teach you how to write an angular app it's not to teach you how to write an express app and it's not to teach you how to use a database with express the goal here is to solely focus on the authentication piece so what i've done in this template is i've done all the implementation for all of those pieces that i don't want to cover and i've left blank the specific pieces that relate to the authentication alright so when you when you clone this and you come back to whatever code editor that you're using you'll go ahead and npm install in the base of the folder and then you also over here i'm in the angular folder so right here you'll go in the angular folder and also type npm install once you've done that then you'll go to the dot env file and you're going to enter these three variables now you don't necessarily have to do this but i guess if you're using this as like kind of a starter you'll eventually need to implement a production database string but this is going to be entirely sufficient right here and then you're also going to have to come over to this script right here generate key pair and we talked about this in the prerequisite video on public key cryptography and this is the exact file that i used in that video and all it's going to do is create an rsa public in private key pair and then it's going to save it to the current directory now our passport jwt strategy is going to use this public key pair public private key pair to issue and verify the jwts so you're going to need to generate this the one thing that i'll note about running this file if you run into an error um trying to run this then it's probably because your node.js version is not great enough i think there is some method here um i don't know which one exactly it might have been the generate key pair sync from the crypto library but it was only implemented in i think it was version um maybe 10 or something you can go ahead and find that we're in the master branch right here but in the final branch you'll see exactly how to start the app and it's it gives you the required node.js version i think it's like 10. let's go let's just verify this right now um so let's go skip over to the final branch which has the final implementation of everything and it's going to tell you that you need version 10 point x or greater to do this script right here all right so make sure that you have that set up and then you're going to just say node generate key pair and press enter and what this will do i might as well just do this right now so let's delete what i've got right here already and then say node generate key pair and you'll see in the left side here it's going to pop up in a second you should see the public and private key pair that i just created um let's refresh it there we go so we have the private key and the public key and you should be good there and then the last thing that you need to know about the setup i think hold on one second that was actually it so that's all you need to do to set up uh you also need to sorry you also need to run the mongodb database in the background um so go ahead and do that before you run the app and then when we actually run this app we're going to um it's not going to work here because i haven't implemented everything but we're going to run node app.js in the root and then ng serve in the angular application and then we're just going to visit the angular application to run the app but that angular implementation is the last video in the series if you're not interested in that then that's totally fine it's totally optional but it's just a common thing to see jwt authentication in a single page application they're pretty compatible so that's why i decided to include that last video that last optional video okay so you should be set up completely with the repository you've cloned it you've done your setup steps now let's take a very quick look at the code i'm going to perf purposely try to fly through this and i'll assume that you're going to go through on your own and get yourself familiar with what is here already but i definitely want to go through a few things here so we'll start with the express app because that is kind of the required piece let's open up app.js and you'll see that we already have kind of our skeleton app set up so of course we have express we're going to import the cores module and the reason being is because in the optional final video where we go through how to implement this with angular we're going to need to make http request from localhost 4200 to localhost 3000 so from the angular app to the express app so you're going to need this course piece in here um path just going to give us access to the um the path that we want to save things in the file system node.js and then we're requiring in passport um the dot m configuration i talked about this in a previous video but basically gives us access to um the environment variables stored in the dot env file and we access those with process dot env dot variable name so that's how you will do that set up our basic express app we're going to import the configuration for the database which is right here um just scroll through here it's basically saying if we're in production environment connect to the production string if not connect to the development string which is just running on localhost and once it's connected we should just get a little message that says it's connected pretty simple there all right so then we require in our database models which is one model and it is the user so let's open up that real quick same exact user schema that we used in the first part of this with the passport local strategy and we're just having a username and then the hash and salt will represent the password in the database then we will require in the passport configuration which is where we're going to configure the passport jwt strategy now it's a little bit weird syntax but basically in the passport configuration we are exporting a function that takes the passport object so we're importing the passport library in app.js and then we're going to pass this variable right here into the configuration function which will then receive access to that and then in the body of the function it will actually do the configuration on that object so that's kind of how that's working we'll come back to that quite a bit so don't worry about it then we will initialize passport this is required for any passport strategy you always have to initialize it so that it runs every time that you make a route request these are pretty simple just body parser middleware except now express has their own implementation so we don't have to do the body parser middleware that you're used to seeing probably so something like app.use bodyparser.json we don't have to do that because express has their own implementation now here's the cores we talked about this line right here is going to allow you to kind of combine the angular and express apps since the angular thing is optional i'm not going to go through it too much but it's going to basically if we come over to angular and type ng build it's going to build all of the assets all the static assets for that application into this public folder and then express is going to use that public folder as the um static directory so in other words express is going to use the angular build as the front end for the application all right so that's what that's doing we're requiring requiring in our routes which should just be um okay so here's a basic route configuration if you wanted to extend it easily you could just add more route files and then add you know another line here that would say something like users will say i don't know something like courses maybe you're building some sort of course module and then you would have something similar to users right here where we have all of the user routes so that's kind of how you would extend that and then in the user routes we just have a protected route which is going to allow us to test whether we did the jwt authentication correctly then we have our standard login and register post routes which is going to allow us to issue the jwt and kind of validate the jwt and finally we have app.listen which will listen on localhost 3000. so that is the basic express app that we're working with and again i would hope that you would go through this and get yourself a little bit more familiar but if you built a lot of express apps in the past this probably looks like a pretty familiar structure now in the angular app i will go ahead and save that we're not going to go through what's happening in the angular app until you actually get to the video on angular so it kind of if you're not wanting to watch that we're not going to go through it and waste your time with that i think i've gone through everything that we need to to get started with the passport jwt user authentication strategy and like the passport local strategy that we did earlier in this series it's going to follow a pretty similar structure so just like we did in the passport local or pretty much any passport strategy we're going to need something called a verify callback so in other words when we're in our routes so say we're in our login route and we pass in a passport.authena method what that method is going to do is call the verify callback that we have defined in the passport configuration so if we open up config js it's going to be defined right here so whatever we define within these brackets is what is going to be called when we use the passport.authenticate method as with any new package let's go ahead and look at some of the documentation so the documentation for passport jwt i have it pulled up right here you could also go to strategies on the home page and click passport jwt to find it so the documentation like most strategies is not necessarily uniform all these strategies are coded by different developers so it's all based on how that developer is going to put it in there so you can see here it's a little bit jumbled up but it gives us most of what we need to know the first thing that i'll draw your attention to is going to be right here and you'll see that just like the passport local strategy the passport middleware as like a framework is going to expect the same three responses so if our callback returns some sort of error whether it be a database error or an express application error we pass in the done callback with the air parameter as the first parameter and then false for the user object then if we successfully authenticate the user we say that there's no error and here's the user object which will eventually be attached to the express request object and then finally if there is no error within our application but there's also an invalid user then we're going to say there's no error but there's also no user so these three responses to this verify callback is how passport knows what to do all right so now we got that covered let's look at some of the options that we're going to be dealing with when we're using the passport jwt strategy so as we know we're going to call passport.use and then we're going to pass in a new some sort of strategy in this case it's the jwt strategy and then that strategy is usually going to take options first and then the verify callback so those options here are going to be defined up here at the top and i will note that most of these options are related to the json web token npm library so if we open that up here's the json web token library this is actually what the passport jwt strategy is using to verify our jwt so all of the options that you see here so there's some examples here's the jwt dot verify method this is exactly what the passport jwt middleware is using and all this strategy is doing is passing in the token that it receives it's going to pass in the secret or public key so there's multiple ways that you can verify we're going to be using the public key since we're using asymmetric cryptography and then we have the options object which is literally going to be just passed straight through to this method from the passport middleware so you see down here we have all the options that we can put in here algorithms complete issuer ignore expiration all of these you'll also see well not all of them but you'll see most of them listed here in the strategy documentation now the way that we actually include these options is a little bit tricky and i actually could not based on this documentation figure out how to get all of these option passed to the verify callback so what i've done is just put together every single option that you could possibly ever need and i've put it in a single options object and then we'll kind of reduce to the only the stuff that we need going back to our code let me just paste in this like all-encompassing options object and i might as i might even leave this in the final implementation just comment it out but here is the full options object if you were to pass in this obviously you need to replace some of these things with valid values but if you were to pass this in it would be readable by the passport jwt middleware so you'll see at the bottom we have the json web token options and this is where it gets a little confusing because here are some of those json web token options that we saw in that library's documentation but there are also options from json web token that are that are passed up here and if you were to pass these down in the json web token options the passport jwt middleware as it's implemented would not actually read them correctly so it's really important that you put the options i have listed here exactly how you see them if you see them in the json web token options they need to stay there so that is the entire all-encompassing option object but we don't actually need that i'll go ahead and put this in the final branch of this repository but i'm going to delete it out for right now and we're only going to work on what we need the very first thing we'll do as with any module is import it so we need the passport jwt strategy and we're going to extract the strategy off that so that's going to be a class and then this extract jwt class which is basically a little subclass that is going to give you options as to how you extract the jwt from the http header if you look at the documentation online you'll see that this is detailed at the bottom so in the section extracting the jwt from the request this just has to do with that process where the server needs to know how and where that jwt is stored in the request usually it's going to be in the authorization http header but it isn't always there so this gives you some options as to where you can find this so we're going to just be using from authheader as bearer token this is probably one of the more common ways to do it but you could also pass it into like a post request body field you could put it in a url query param and if you were to do that you would use these different methods from this class you could also write your own extractor function so i know i mentioned earlier that you could put the jwt in a cookie and this right here just gives kind of that example this is how we would grab it from a cookie and so you can kind of have some freedom to implement whatever you would like so our options object is going to be pretty simple just going to replace this right here and this is what we're working with so this is the options object that we're going to need to implement the jwt strategy first is what we just talked about the extract jwt class comes with different methods for finding that jwt and parsing it so we're going to use the from auth header as bearer token so in other words it's going to expect that we have our jwt sitting like this so here's our authorization header and then we're going to say bearer and then a single space and then here is where our token is going to sit so it expects this exact syntax and if you were to maybe take the space out or just delete the bearer portion completely it's not going to be able to read it correctly you'll see how that works a little bit later the next thing is the secret or key property and you can either pass in a symmetric or key which would just be a secret that you stored in an environment variable but for us since we're using the rs256 algorithm to issue and verify jwts we're going to pass in our public key that we generated with that script right here and we're reading that from the file system it says path to key id rsa pub and the reason that we're passing in the public rather than the private is because what we're configuring right here is the verify piece of the jwt so if you remember we have the issuance and then the verification with a digital signature we sign the issuance with the private key and then we verify the identify or we verify the identity with the public key so that's why we're passing in the public key because passport is the verification step of this process then finally we're just passing in the algorithms that it will accept and we should be done with it so that's our options object obviously we didn't include half of the options that were available to us but i just wanted you to know that those were available in case you were doing something a little bit different than me like i did with the passport local strategy i'm going to kind of deconstruct this configuration so that you're not just looking at a big blob of you know callback functions and options and all that stuff so we're going to keep it as modular as possible here the first thing that we do we have our options object already configured but we need to use the well jwt strategy right here so we're going to say const strategy equals new jwt strategy all right so that is going to take two arguments one being the options object that we defined right here and two being a callback function which is going to it's already telling us what it expects so it's going to take a payload and a done callback all right so that is the basic implementation right here and then we're going to actually configure it by saying passport.use strategy so again this passport object is being provided from app.js then we're taking that object we're saying use so similar to a middleware and then we're passing in the strategy which has the options configuration in the callback function or the verify callback that we are about to implement within the callback as i mentioned with the passport local strategy the great thing about passport and also the confusing part is you don't have a specific way that you're required to verify in authentication and in our case we can use whatever database we want we can use whatever you know code logic we want to do now since we're using mongodb we'll just use the find one method on the user model so we've imported this from our database configuration so we'll just say user dot find one and then we're going to pass in the id and where are we going to get this id from well if you remember from previously in this i think is in the first video we talked about how the jwt payload so the second part of a jwt is going to have a subfield well in our case it has a subfield and in many cases it has a subfield that will include some information or unique identifier about the user in our case when we implement the register and login functions or the routes we're going to issue a jwt and we're going to place the mongodb database id in the subfield so here's our payload this is in javascript object form so we can literally just say payload dot sub and that's going to pass in the id that we need to look up our user in the database we will then use promise syntax to grab the user and then we will catch any errors that happen and if you remember we need to pass in the error to the done callback if we um and no user if there's an error within this operation so the last thing we need to do is something in this area where we have access to the user that we just looked up now if you were watching the passport local strategy you'll probably remember that in this area we were doing all sorts of stuff we were verifying um you know using a crypto function we were verifying the username and password well in this jwt strategy it is much much simpler we are just we've already validated this jwt so this strategy has already gone through the process of using the json web token library to verify the jwt that it's received so at this point when we're sitting right here we already know that our jwt is valid so all we have to do is check if we found a user in the database and if we did we need to return it to passport so that it can attach that to the request object so we'll just say if there's a user we will return done and there's no error but there is a user otherwise we're going to return done and we're going to say no air and no user excuse me this is not null this is going to expect false so passport expects to see either a user object or false so that is the implementation that we need to do for this verify callback it seems like nothing really is happening but behind the scenes the passport jwt strategy is taking these options it's grabbing that jwt from the authorization header it's validating that jwt with the json web token library then once it's validated it it passes the payload object right here then we grab the id of the user from the payload sub object look it up in the database return it to passport and then passport attaches it to the request.user object within the express framework so that is all that we needed to do to implement passport jwt now i would try this out in the browser and you know see if it's working so far but the problem is we haven't issued any jwts so we could go generate a jwt or grab an example from online and see if it would work with this but it never will because we have generated exactly zero jwts using the private key that we generated in this repository so in other words when passport jwt strategy tries to verify the jw jwt we've included in the authorization header it's going to reject absolutely everything because there is no jwt in existence right now that corresponds to this private key so when we verify it with the public key it's just going to reject it so what we need to do is write some logic in our login route so that every time a user logs in we're going to issue them a new jwt that is signed with the private key that we are using from this server then the passport jwt middleware will use the public key that resides on this server and will successfully verify these new newly issued jwts so to do this we need to come to the routes so we're in the routes users.js file and the first thing that we'll need to do is the register function so if a user is going to come to our application they obviously need to first register and basically what's going to happen in both of these routes is we're going to issue a jwt regardless so the way that this flow is going to work is if a user comes to our application and has never been there before and registers they're just going to provide their username and password then we're going to store that new user in the database and issue them a new jwt and then we're just going to consider them logged in for as long as that jwt is valid and then the login is also going to issue a new jwt but it's just going to look up the existing user in the database and validate the user the username and password that that user put in there when they registered if you watch the passport local strategy videos you're going to be very familiar with what i'm about to paste in so what we're doing here in the register function is we are taking the plain text password that the user has provided us with and we're creating a salt in a hash based on that plain text password we're just using some crypto utils so if we go in lib you'll notice that these these two functions valid password and gen password are going to be the same exact um generation and validation functions that we used with the passport local strategy and so you might ask yourself for a second well wait a second isn't this jwt isn't this a jwt strategy like why are we working with like username and passwords and all that kind of stuff well you have to remember that the jwt is simply a result of a successful user authentication with a username and password so whether you're using the passport local or passport jwt authentication you're always going to need to know how to store a password in the database and then verify it out of the database i'm not going to go through that if you wanted to really understand how this works i do have a slide on that let me just pull it up really quickly so here is the basic password validation process since i talked about it in the passport local strategy a lot just go watch that video if this doesn't make sense otherwise just read through this really quickly all right so that's basically what's happening with the password generation and verification and in the register function we're doing part one of that so we're going to create the salt in the hash and store those in the user record in the database then we'll save the user in the database and just return a success message as well as the user object now i also mentioned that we're going to be issuing a jwt here which we will do in one second but i want to first look at the function that is creating that jwt so we go to the bottom of the utils and you see that we have exported this issue jwt function which is defined here and since the passport jwt middleware is using the json web token npm library we might as well use the same library to issue the jwt so what we're doing is we're taking in the user object that we have in the database we're going to take the id of that user in the database and we are going to assign it to a variable here we are going to say that we want this jwt to expire in one day usually you'd probably do this like two weeks or something but we're just going to do one day for now and then the payload of this jwt is going to be defined as the sub property we'll have the id as we talked about when we were configuring the passport object and then the issued at will just be whatever time stamp is right now then we will sign the token and we're going to do that using the dot sign method of json web token library we're going to sign it with the private key we imported this up here at the top so here's the private key that we imported and that private key corresponds to the public key that we're going to verify later with then we're going to pass in the expires in value and algorithm that we plan to eventually verify it with and that we will sign it with so once we've signed the token we will return a token which has the bearer string at the beginning and then the sign token and then the expires in property so we have this function that's going to issue a new jwt signing it with the private key living on the server and then we're going to come back to our users routes and then in the success message we're going to attach a token and then a expires in property and to do this we just need to um well actually we're going to want to do this down here because when we initially create the user we don't have the id that was stored in the database yet so we need to come down here in the callback to get that id so we'll say the id is equal to user dot id and then we're going to issue this jwt so i think i've already included the utils library so we've got the utils library up here so we're going to say the jwt is equal to utils dot issue jwt then we're going to pass in the user and actually i don't know why i did this right here the function itself is going to grab that id off of the user object so all we have to do is pass in the user and then if you remember it returns us an object with a token and expires property so we're just going to grab the jwt dot token and jwt dot expires and there we go we have a successful response and once we have saved this user in the database after registering the front end client will get this message right here so let's do that really quickly let's run this make sure that we don't have any errors going on looks like the database connected okay and i'm going to open up postman which is just an http um request application it's got a lot of other stuff i should probably be giving it more credit than that but let's go to register i've already got the post request set up and in the body we're just going to require um i think it was just a username and password so we'll say the username will be zach we'll say zack jwt just that we can distinguish from the passport local strategy i was doing in a previous video then the password will be just one two three my default debugging password here so i think that's all that we need for this request let me just check that really quick okay so this is all we need we should be able to run this and hopefully it works um let's see what we got for the response looks like we had some issues so let's go back and see what's going on um hmm oh of course we have the wrong route that we're using i just said register it's actually going to be i think users slash register or even maybe even api slash users we'll find that out real quick come back to the code let's look at our index.js okay so we're going to okay so it's the slash users route is what we're going to need so come back to postman get rid of this api we didn't include that now we should be able to send it and we get a successful response so here's our response success is true here's the user that we stored in the database and we'll verify that in a second and then here is the token and the expires in that we issued using the utils library that we wrote all right so this is what the frontend is going to receive as a response and then they're going to take this token and store it somewhere in local storage so that it can attach it to every single request in the future implementing the login post route is a little bit more complicated but i'll post in the implementation or paste in not post i'm looking at all these post requests and what we're doing it's it's pretty simple but there's a lot of code here so we'll start at the top the first thing that we're doing is we're going to take the username that we received from the login form whatever the user typed in and we're going to look in our database for that username if we then will assume that we find the user and we populate it in this user property we'll say first if there's no user so if this user in the database doesn't exist maybe this person is trying to log in and they haven't even registered we'll just return a 401 code with a message that says could not find the user pretty simple there this next line if you watch the passport local strategy you'll understand this exactly but if you didn't what this is doing is using that valid password function so up here the validate password function and it's basically going to check okay is the username um that you just gave me and the password you just gave me are they valid so it's going to take that plain text password that the user just typed into the login form and validate it with the node.js crypto library and that function that we already defined so this is going to either be true or false based on whether the user logged in successfully and mind you this is different from the jwt remember we have not issued the jwt yet we'll just assume that they're logged out so if this is valid we know okay this is a valid user we need to give them a jwt that they can attach to all of their future requests so that they don't they don't have to log in every single time so here's our issued jwt it's exactly how we issued it down here and then we will attach that with the same exact response body that we did earlier we also probably should just put in the user property here like we did in the register route and then finally if the user did not log in successfully they gave us the wrong password or the wrong username whatever then we will return this response where it says you entered the wrong password and it's just going to be a 401 response because that is like the unauthorized http code all right and then we're going to catch any errors just put it through standard express middleware and catch it in our air handler i don't even think we have one implemented for this but that's kind of what that's going to do all right so we've got both of our routes implemented and let's come back to postman just make sure that this is going to work alright so we'll go to login and let's just copy the body that we put for the register because it should be the same so here's the user that i already have registered in our database um here's the correct password for that user let's make sure that we have the right path here and click send and we get a success is true and we get the same exact response here is our jwt that we will store in the browser at some point all right so we are done with the bulk of our work here the last thing that we need to do is just test to see if our passport jwt middleware is working correctly so far we haven't even tested the passport jwt middleware we've just be been doing the basic username and password register and login and issuing the jwt all right so coming back to vs code the way that we're going to test this is in this first route which is the protected route and we are going to pass in the passport middleware right here so we'll say passport.authenticate and then we're going to say that we want the jwt strategy and we're going to pass in an object that says session false and the reason that we do that if you're familiar with the passport local strategy that we did in previous videos we were using the passport session middleware to actually interact with the express session middleware but we're not using this here because we're using jwts so we say that that's false all right so what this is going to do is execute that verify callback so this function right here and if we successfully validate the jwt that has attached the request it should let us into this route so we should be able to print something let's see if we can get in here all right so we'll just say res.status200.json.com will stay consistent here is true message is going to be you are authorized we are now ready to test this out so let's go to pat to postman and we'll come over to the protected route again we need to put in that path and here's where the magic comes in but also kind of gets really confusing we have to attach the jwt that this user owns to the authorization header now in postman you have the option to put it here in the authorization tab you could just do bearer token and you put the token here but we're not going to do that we're just going to stick with basic http headers to keep things simple so we're going to use the authorization header and then the value that we will pass in is that token that we received over when we registered or logged in so we just logged in so we're going to take this entire token including the bearer portion and we're going to copy that into the value right here so this value because it's in the authorization header and because it says bearer with the space and then the token which is exactly what the passport jwt middleware is expecting that middleware is going to take this value it's going to run it through the verification function using the json web token library and hopefully authenticate us correctly so we're just doing the get request let's send it and it says success true you are authorized so in this case we just copied in the bearer token here the jwt in postman but obviously if you're implant implementing an application you're going to do this on your front end client so for example angular and you're going to want a way to you you'll probably store it in local storage after you've been issued this and then you will write some sort of logic to attach it to every request but that's not the purpose of this video this video is just to show you how to configure the passport jwt strategy so if you wanted to watch that that'll be probably the one of the next videos or something like that but the last thing i wanted to do in this video is just kind of a quick recap to show you exactly how you're going to be using this alright so every time every route that you want to protect using jwt authentication you're going to use this syntax right here if you wanted to simplify it even further you could probably write write yourself a middleware that just calls this method and then you only have to pass in like a couple letters but if you wanted to you can pass in this exact syntax every single time now this is very different from the passport local strategy because if you remember when we did that if you watched that video we only called the passport.authenticate method one time and we called it in the login post route and then after that what we were doing to check whether this user was authenticated was saying if request.session.passport.user exist or i think we had a shorthand method if request dot is authenticated that's how we were validating whether a user was logged in but since jwts are by default stateless we're not using sessions we have to call this every single time so that the passport middleware can you know grab the jwt that's included in the request and verify it so it's pretty simple actually this all you're going to be using attach it to every request that you want to authenticate and you could even come over to your passport verification and have some sort of different logics you could say in this part of the body you could say if user.admin if you wanted to validate like an admin property or something you can get pretty creative with it but that is the basics of using the passport jwt strategy i just want to take a few moments to say congratulations if you've made it to this point the remainder of the video is completely optional for you you can fully say that you understand the basics of user authentication in node.js express and passport.js if this video has connected the dots for you in one way or another i'd really appreciate if you went and checked out my channel um much smaller channel than the one that i'm on right here but i make a lot of web dev related videos and post on a weekly basis at least at this point so go check it out subscribe like a video that would be extremely helpful to me and i'd really appreciate it alright the last part of this video as i said is completely optional and we're going to be covering two things number one we're going to be covering how do we actually take passport js out of the equation with the jwt strategy believe it or not the passport jwt strategy is just using the json web token library under the hood and we can do the same thing well passport js has a lot of strategies that really alleviate a lot of the work that you would have to do and i'd highly recommend using them the jwt strategy is a little bit unique in the fact that i don't think that the passport jwt strategy adds a whole lot of incremental value to you now that is of course if you understand what you're doing and since we just talked for many many hours to learn how all of this works and we actually do know what we're doing we can implement our own jwt strategy pretty easily and then in the final part of this video we're going to walk through the basic implementation of a jwt strategy with angular on the front end now of course this will not apply to all people not everyone is an angular developer or has an interest in that but i did want to tack it on to the end in case you are working within the angular framework and are confused how do you take all these concepts and translate it to you know the front end and use local storage to keep your users logged in and communicate with the backend that we just wrote all right let's go ahead and first jump into how do we write our own custom jwt authentication strategy so what you see on the screen here is our application it looks a little bit different got a slightly different environment as i'm recording this video which is kind of recorded a separate time as an addition to this course so everything is the same though don't worry about that let's go ahead and open up postman just so that i can prove that out to you so if we go to the register route we'll put in another test user and we'll send that request and it's not going to work because we're not actually running the server at the moment so let's go ahead and run the server try that again and we should get a successful creation of the user now let's copy these same credentials oops we'll copy the same credentials into the login right here click send and we should get a bearer token let's copy that bearer token go to our protected route and drop that into the authorization header value click send and it says you are successfully successfully authenticated to the route so as you can see it's the same exact thing nothing has changed but what i want to do now is close out of here and i want to create a new branch so we're going to create a new branch called custom jwt and what we're going to do on this branch is we're going to completely rip out the passport js implementation and add in our custom jwt implementation you might think that sounds really difficult but it's actually not and although there is a really good use case for passport passport as a middleware and framework such as the local strategy and a lot of the delegated authentication such as you know the social logins truthfully the passport jwt strategy does not really do a whole lot of heavy lifting for us quite honestly i prefer to do my own custom implementation when working with jwt so the most obvious place to start is going to be in the passport.js file where our implementation sits let's take a look at what we might have to change so the first thing that i see in the options is that we have this method called extract jwt from auth header as bearer token so we need to be able to take the off authorization http header and grab the correct token and parse it in our code as i mentioned earlier passport js is doing that for us so we don't have to do it on our own but as we're ripping passport out right here we're gonna have to write a custom function to do this furthermore in the main implementation this is just a middleware so we're just going to replace that with our own custom middleware function that's all it really is is just a function and we're basically going to verify the jwt that is passed through the request and then you know either authorize or deny access to that given route and then that's going to play out once we go to the routes over here where you see in the protected route we're using this passport.authenticate method we're just going to replace that with our custom middleware function that we're about to create so just to start us off let's go ahead and and start removing some things so let's comment out the passport declaration up here and let's also remove the authenticate method right here and see how that changes everything for us so we should still be able to start the application and then go over to postman go to the protected route and we can uncheck this authorization and click send and it says you are successfully authenticated now that's obviously not true because what we did was just remove the middleware that's authenticating us so we need to replace this with some other middleware and we're just going to throw this in the utils file because we've already got this being imported so let's open up utils and you can see we have a lot of our helper methods in here and what we can do is actually create our authentication middleware as well so let's go ahead and create a new function and we'll say this function will be called off middleware something like that and what we need to pass in as with any middleware is going to be the request object the response object and next and then of course we're going to create that as a function so we'll drop it down here by default let's go ahead and just send a 401 unauthorized error so the 401 http status code is for unauthorized and if we were to um let's save this go back to our users right here and add back in the passport authenticate method and then uncomment or yeah uncomment the passport import this is going to put us back to where we were and if we go to this protected route and we've got the authorization removed and click send we should get this unauthorized response and if we click through this let's see we can look at the headers and it says the status is 401 unauthorized and then it explains that error similar to 403 forbidden but specifically used for when authentication is possible but has failed or not yet been provided so that's a good just overview of the 401 error and we can also see that we're doing this in the res dot status right here uh in the login route so we're already a little bit familiar with this but by default we're going to make this off middleware just send that 401 and maybe we can even stay consistent with our login so instead of just sending it we'll say res.status and then give it a payload or a response body so we'll say res.status is 401 the success is false and the message is going to say you are not authorized to visit this route from this point let's go ahead and copy one of these down and replace our export so that we have the off middleware export so that's going to export it from this file and now we can actually use it over in users.js so we've got this import already so let's let's comment out passport again just that we're not we're not importing that anymore and we can we can go ahead and delete that because we're not going to toggle that back on yet or anymore so we'll go to utils.off middleware and that's really all you have to pass in you don't have to pass in any you know parameters or arguments or anything so let's go back to postman and try out our protected route so let's click send and see what the response is we get a success false you're not authorized to visit this route and the reason we're getting that is because when we run this route instead of getting what's in the body of the route we're passing through this off middleware that we just created and it's by default giving us an unauthorized status but that of course is not what we are wanting to do here we're wanting to get the jwt that was passed into the request and then pull out the token from that and validate that token using the json web token library because after all that's all that passport jwt is doing in the end what i have pulled up here is actually the passport jwt strategy implementation and you'll see that on the verify jwt this is all that's happening you're just using the json web token library to verify the token itself so that's not going to be all that difficult for us to do and then furthermore we have the extract jwt which is going to be if we come back here go to passport and see this method right here so the from off header as bearer token so if we were to go to that same repository we can go to the um off header or no the yeah the offheader.js which is going to have a parse offheader method which is going to basically call the extract jwt and then this has a bunch of different ways that we can do this depending on what our header looks like but in our case it's from auth header as bearer token as we saw right here and what that's doing is calling another method which has some utility functions so on and so forth so that's not all that difficult to implement either let's go ahead and see what that request header looks like so if we were to drop into the off middleware in console.log the request and then i believe we can just say the request.header if i'm remembering this correctly and then we came over to postman and we went to the headers turned back the authorization header and click send and then we'll see something printed here so maybe i did not uh print this correctly so i'm printing a function not the actual header so i think i have to say request.headers maybe instead so let's go back send this request again and now we're getting something a little bit better so we're seeing our header printed out now let's go back to postman and instead of this authorization header let's go ahead and copy the token itself and turn this one off and then go to authorization and click bearer auth so if we copy in this token and click send we should still get the same header so we we're always going to get this authorization property and that's kind of what it means when we're looking at the passport implementation and it says that we need to extract jwt from the auth header as bearer token that is us telling the passport library hey we expect this certain format so parse it accordingly so that's basically what we're saying is we always expect this exact format to be passed in and in our utility method we're going to have to take that into account so the next question is how do we actually parse through this token well we can actually split the token because as you see in the format down here there is no spaces other than between the bearer and the token itself so if we have a valid bearer token we can just split it with a javascript method so let's go ahead and make a variable called token parts and then what we're going to do is we're going to say request.headers.split and we're going to split it by a single space now if we console.log the token parts instead of just the entire header you're going to see something that we can work with a little bit easier so let's go ahead and remove this we'll go back to no off because i think it's a little bit more straightforward when we're just passing in the authorization header and let's go ahead and click send and it looks like we got some issues here it says request.headers.split is not a function and that is of course because i'm not thinking at all trying to talk and teach and code all at the same time it's a little bit difficult sometimes i don't want to split the headers i want to split the headers.authorization property let's try that that might work a little bit better and this time we should get an array so our array has the bearer and the token keywords and then from here we basically need to check to make sure that this is the correct format because what if what if we get something that's incorrectly formatted passed as an authorization key that would obviously be invalid so what we're going to do here is we're going to say if the token parts 0 is equal to the word bearer which is what we would expect and the token parts number one so the first index which would be the actual token if that matches a certain regular expression then it's going to be valid in that regular expression as we learned with the jwt portion of this course is always going to be a series of characters with a period and then another series of characters with another period somewhere here if i can track it down and find it so right here is the second period and then some more characters to follow so the way that we can validate that is with a regular expression that basically just looks like characters period characters period more characters if it doesn't follow that format then it's invalid we don't want to let the user into the route so we can actually use the string matching function and we can pass in a regular expression that i've already written so this course is not about regular expressions so you're just going to have to take my word on this this right here is going to basically say look at the string that we've got down here and ask you know whether it fits that format of characters dot characters dot characters and if it is then it's not going to equal a value of null so if it does match then it's going to give you a results array if it does not match it will return null so if we check and make sure that that does not return null then we know that we have a valid jwt format so we're basically saying if we make it into the body of this if statement then our token is valid we are now ready to actually write the verification portion of this with the json web token library now we've only imported our private key up here but we also need to import the public key in order to validate this so remember we sign it with the private key and we verify it with the public key so that's the order we're going in so let's go ahead and copy this down and we're going to grab instead of the private key we're going to grab the public key and then we're going to change the variable name copy this down change private key to public key and update the variable here let's make sure that we're getting that correctly first so if we get here and we have a valid token which we should we should be able to console.log the public key constant variable so we restarted let's try to visit the protected route and you can see that we're getting that public key printed out just fine so that's working now we just have to implement the json web token verify method that it comes pre-built with so if you were to go to the json web token documentation on npm and search for the jwt dot verify method you can see that it takes in a token which is going to be the jwt a secret or public key so that will be our public key and then of course we have some options and a optional callback function you can read through this but i'm going to go back and just implement it and show you exactly how to use it so we've got the imported json web token library and all we need to do is come down in here and say let's say verification variable equals json web token dot verify now it's going to ask us for a token which we're going to give it the token parts at index 1 which is the actual token we're then going to pass in the public key and then in the options it asks us whether we want to supply an algorithm so if i were to go back to this documentation we have an options and algorithms which is a list of strings with the names of the allowed algorithms for example hs256 blah blah blah so all we have to do is pass in the algorithms and then in the array we need to pass in rs 256 and you might ask how did i decide on that algorithm well if you remember from the passport.js file where we were given the options to the passport middleware we were basically saying i want to extract it as a bearer token which we did here in these lines right here then what we said is i want it to be using the public key so we passed in the actual public key just as we did right here and then finally we said that we wanted the rs256 algorithm which is basically the public private key pair or asymmetric cryptography so that's what we're doing here in the algorithms section so we're basically giving it the same options we're just doing it more directly so let's go ahead and console.log the verification and see what we're getting so let's go back to our postman if i can get there and click send so we sent the request we'll come back here and we're getting this value right here which is going to basically be an invalid value if it was not successful or will get this object if it was successful so let's go ahead and manually put in the wrong key to see what happens if it's not so we'll just remove this first e at the beginning of the bearer token and click send and now we're going to go back to our library here and it's going to say json web token air invalid token as you can see here this has thrown us an air and we don't want that in our application we want to handle all of our errors and if we were to go back to our documentation here for this method it's going to give us an asynchronous way to do it and a synchronous way to do it let me just get rid of this search so we don't see that and for the synchronous method it says if a callback is not supplied function acts synchronously returns the payload decoded if the signature is valid and optional expiration audience or issue issuer are valid if not it will throw the air so that's basically telling us that we need to handle an error if we're doing it synchronously which is how i want to do it here just to stay simple so we can use the built-in try catch block so we'll say try catch and then pass in the air and if we go ahead and run this method right here if i can copy it correctly if we run that right there it should pass and if it if it does not pass it will throw an error and at that point we can console.log the error just to see what we're dealing with so let's go ahead and see if we can verify it so basically if we don't make it to the error state then we know it was successful so we've reconnected let's send the request with an invalid request and you'll see that we have printed out the air now so it looks like it through the air but we're actually just printing it and handling it gracefully so based on this all we need to do now we've just kind of tested everything out let's get rid of this console log statement let's also not print a variable that we don't have anymore that's a problem and then we'll come down into the catch block and if we have an error that's where we're going to put this status of 401 so as of right now if it was successful it's not going to do anything it's not going to return anything if it's unsuccessful we're going to get this message right here so if we go back to postman we should expect to get the you are not authorized to visit this route message which is what just happened so that's working great and now what we need to do let's go ahead and assign this to a verification variable once again and now what we're going to do is pass the next callback in here so we'll just say next and that's going to pass us through to the next route at this point what we could do is we've got this verification stored and let's go ahead and console.log it one more time just to see what we're dealing with and at this point i need to add back in that uh e character that i just manually removed from this token so now it should be valid and when we send the request we're not going to get any response yet because we haven't done anything here but in the terminal if we scroll to the bottom we should get this little block of code which is some useful expiration date of the jwt token which we can then use on the front end to you know set expires headers or expires in local storage and stuff so it would be helpful to pass this along so all i'm going to do is say on the request object i'm going to going to assign the jwt equal to the verification and then i'm going to say next to pass it to the next middleware in the chain so at this point we're passing it to the next middleware in the chain and now we have this jwt property so we're going to drop into this route and now we should be able to console.log the request.jwt and if we console.log that successfully then we know that it was a successful verification and we should see the same object being printed despite the fact that we're not printing it in our middleware anymore let's go back to postman click send and it says you're successfully authenticated which is good good news and you'll also see this jwt that we had attached to the request object so believe it or not we are done ripping out passport.js and implementing our own strategy so if we were to come to the passport.js file and just click delete on this whole thing we should still be able to run our app so let's start it it's going to crash because we're currently importing that into app.js so if you remember we're configuring passport right here and do we do anything else yeah we're importing passport up at the top just want to make sure we're not using it anywhere else let's save that and see what else looks like i missed one so on line 22 here's the initialization call we'll delete that out click save and it looks like we're compiling correctly now we've deleted passport entirely i don't think that we have any other references to passport let's go ahead and check so that's just in the package json and then the readme so we're looking good we have no more references to the passport library in our code and now we should be able to go through the entire flow that we went through previously with our custom strategy so let's go ahead and try it we'll start with the register route we'll put in a new user click send we've created the new user we will update our login route to log in our new user we'll click send there we've just been issued a new bearer token and then we'll come to the protected route copy in the bearer token and click send and it says you're successfully authenticated if we you know delete some stuff here and pass in an invalid bearer token and click send it's sending the request and not returning anything for some reason and i've actually got an error in my code that i forgot to account for because it's not returning a request so the reason that's happening is because remember we're verifying whether this is a valid token in the first place and only if it's a valid token are we trying the verification so we need to provide an else statement to catch any time where the the actual syntax of the bearer token is wrong and we'll return the same unauthorized status if that's the case so now if we come back and click send we should get an unauthorized response so i'm glad i caught that but basically that's just a demonstration of how we implement our own custom jwt strategy and it's what i use in a lot of my apps for when i'm just getting started and you know providing a basic authentication strategy once again you can check out the github repository associated with this course and go to the custom jwt branch to see the code that i just worked on and last but not least let's go through how do we implement this jwt strategy on the front end and sync it up with all the code that we've written on the back end in express today we're going to be talking about how do we take the passport jwt strategy that we implemented in our express application and kind of port that into a frontend that will handle the jwt and attach it to each of our http requests so we're going to do this with angular and the reason being is because i for one know angular better than most of the front-end frameworks and number two it is very compatible with jwts now if you were to um let's say make an express app and you used ejs as a templating language and that's how you built your front end now in that case sure you could you know somehow implement a jwt front end but it's going to be a little bit more difficult because the pages that we would be loading on the front end are going to be coming straight from the server well as in an angular application it's an spa or single page application which means everything happens in the browser so that includes the um the jwt stuff and so it's just very compatible for what we're doing here like i said in previous videos the goal of this one is not to teach you how to write an angular app so i'm assuming that you already know kind of the basics of angular we're not going to do anything too crazy but i'm not going to be walking you through the structure of how angular works and all that good stuff the goal here is to show you exactly how we take our express server that is issuing us jwts and translate that into the front end so to do that i want to first walk you through what i've already provided you with in the previous video i introduced the github repository it'll also be in the description here and when you download the repository on the master branch you're going to have a blank template we implemented the first part of that template in the express application in the last video and then the second part of the template is what we're going to be doing in this video and that is sitting in the angular directory and if we open up the main part of this application you'll see several folders already built for you and they're all connected up so this app kind of runs already even though we haven't implemented the actual methods so i'll walk you through it real quick let's start an app.module let's see what we've got here so i've already set up the routes for us so if we visit login register and protected it's going to load the login register and protected components so that's already set up for us in angular kind of gets that out of the way we are declaring those components here let's see here's the router module and this is important we have to implement the use hash option because we have our api from the express application and then we have the routes from the angular application and we don't want those to conflict now down here i kind of debated whether i was going to put this in here but this is the setup for our http interceptors and that is something that we're going to actually implement but i've left the the structure of it intact and it's already included in the main module so you don't have to worry about doing that but this right here is a very special syntax you're probably not used to seeing it if you don't work in angular a lot so that's the app module which is the base of the application app component just has three links so that you can load each of the routes and then i actually put the routes below so we're pretty much staying on one page the whole time and just toggling between the routes by clicking these buttons up here i can go ahead and run this just so we can see what that looks like i don't think we should get any errors so it loaded successfully let's visit in the browser and you can see that our application is very far from beautiful the goal here is not to style it up or anything we just want the functionality so as i said if you click each of these routes they're going to display below so right now we're at the home route so nothing is being displayed but if we click login you'll see a little ugly login form if we click register you'll get the register form and then the protected route is just going to give us a message and in this case we don't get a message because we're not authenticated so that's kind of the the entirety of this application obviously it's not something that you would show to any user but it does give you the setup and the the logic behind how you would start an application okay so let's come back to the code walk through a couple more things that we've got set up and i'll kind of show you what we're going to be doing in this video so the first thing we've got is the off service this is a service that we're going to be spending a good amount of time in as you can see we've got five different methods that we need to implement in order to kind of manage that jwt that was issued from the express server next up we have an auth interceptor which we have to implement the intercept method for this what this is going to do basically is take each http request and it's going to attach the jwt to it so this is kind of the magic behind the scenes then of course we have each of our components so the login protected and registered components let's see what i have implemented here we we basically just have the form functionality implemented so we don't have to walk through that logic so you see here we have a register form then when we submit the register form it's going to call this method which sits right here and in this on register submit we're just going to take the username and password we're going to make a post request to our express application which is on localhost 3000 and then we're going to get a response and if it's successful then we're going to navigate back to the login so don't worry too much about what's going on here this is basically just making the request to get the jwt from the express server and then same with the login you're going to see something very similar you have a form here you have a method on submit and that method is going to make a post request to the login route of the express application so go ahead i know i didn't cover absolutely everything so go ahead on your own time and just pause the video and take a look through this angular app just get familiar enough with it and then we will get into actually implementing the jwt um strategy here i think the first thing that we should do is implement this service called off service now this is going to manage how we store and retrieve the jwt token or jwt that we have been issued from the express server before we do that though let's go and quickly review what we're getting from the express server so if you remember from the last video when we register a new user let me go ahead and register a new user real quick we send that oh and it's not going to work because the express app is not running yet so we need to first run the express app okay express app is running we can go back and actually let's how do we cancel this request um cancel all right so let's send it one more time this time we should get success true and here is our jwt so this is how we're getting information from the express server and then if i wanted to log in with that same exact user i could do that with the login route and it's going to give me the same exact data so this is the data that the angular application expects and once we get that data we're going to basically take this token and put it into local storage so that is what this auth service is doing it's basically saying okay once we get the response we want to set local storage then the logout method will basically delete stuff from local storage so on and so forth to help us out and kind of keep things straight um in our heads i'm going to copy in this response that we get from um the express application when we register or log in a user so i'm going to put this here and just comment it out so that we have a representation of what we are expecting to receive and this when we implement this first method here the response object should be this right here so the first thing that we need to do in the set local storage this is going to be when we receive our jwt and we need to put it in local storage so the first thing that we need to do is actually figure out when this jwt expires so in the response body up here we're going to get a value of one day to make things a little bit easier and not have to deal with javascript dates and stuff we're going to use a library called moment.js which is here's the documentation for that and it's pretty simple to be honest moment is the main function gives you the current moment and then you can do whatever you want with it you can format it here's like the live on the right side here is like the live updates to these pieces of code you can also do things like add certain amount of days so this is what we're going to be doing we're just going to be doing moment.add and then pass in that 1d which represents one day so come back to the angular application we're going to just store let's say expires equals moment dot add and then we're going to say the response object dot expires in alright so we've got the response object right here and then the expires in property so basically this right here equals 1d and if we add that to the current moment that's going to give us the time that this jwt expires after we've figured out when this jwt expires we need to set two things into local storage to do that we can just say local storage dot set item and this set item method is going to take two values so first is the name of or first is the key and second is the value so we'll say token is the key and then the value of that if we look up in the object that we should be getting here it's going to be dot token so we will say response object dot token and if you remember that token is has the bearer included so just keep that in mind as we go forward local storage dot set item and expires so that's going to be our second one and that is going to be the response object as well but we actually have to do a few things to this or excuse me this is not on the response object it is what we just set right here so we need to pass in expires and then we need to do a few things to it so first we need to get the value of this so this is just a javascript method that's going to take the primitive value of a string object and then we will say json.stringify and pass in that value so nothing too special going on here it's literally just to get us in the correct format and that's pretty much it for the set local storage method so we'll receive this object when we log in or register and then angular is going to take that object pass it into set local storage we'll see where this is actually used a little bit later but it's going to take that response object and set these two items in local storage now to log out we're just going to remove those two items so we can say localstorage.remove item and we just pass in the name of the item that we want to remove so once we remove these items from local storage when angular checks to see whether they exist it won't find them and it will make the user log in again so that's kind of what is going on here the next thing that we're going to do is this get expiration method and that is because this method is going to be required to see if a user is logged in now if we issue a jwt to a user then that means from um that the express application has already done all of the crypto cryptographic logic to decide whether the user is actually valid so if the angular application receives this response then we know that they are pretty much logged in so all we have to do is check whether the jwt is expired and if it is expired we need to delete it from local storage otherwise we can consider this user to be logged in so to grab that expires from the local storage we're just going to paste in a few lines here so first we're going to get the item it's not expires at it should be expires as we set it up here and then we're going to figure out um the so json parse is going to take the json our object and make it a javascript object this last return value is just going to calculate using the moment library it's going to just calculate the point in time which this jwt actually expires and then we'll come up in the is logged in route or not route but function and we're going to take this value the expiration value and see if the current time is before or after it to do that we just say return moment dot is before this is just a method that we have available to us and then we're going to pass in this dot get expiration which will return us the moment that this jwt expires and if it returns true then that means that the jwt is still valid and we should still be logged in then the last method here is just going to return the opposite of this dot is logged in pretty simple now that we've implemented this off service let's go ahead and see it in action before we do that i want to remind you what is happening when we register a user using the register component when the user presses submit on the register form this post request is going to be sent out to our express application which is running over here which will return that big object that we were talking about and looked at and then once we receive that response object we're going to pass it into the set local storage method which will set our token and expires properties in local storage let's test this out go to google chrome right now if i refresh the page you'll see that in the application we don't have anything in local storage for this application now let's go to the register route and let's put in something like jwt test and then a password of one two three and when we click register we should be redirected to the login route and you'll see that these two the token and the expires has been set to the local storage we also will console log the user object that we got back from the express server just to see that it was successful at this point we actually don't even need to log in necessarily because we've got these things set in the local storage but why don't we just go and do it jwt test one two three and then we're going to be redirected to the protected route but it says you are not authorized to visit this route no data is displayed and the reason being is because we have not yet implemented our interceptor which is going to take the jwt that is sitting right here in local storage and append it to every http request that we make in our express applica or our angular application in other words we need to find a way to when we click visit protected route while there is a token that is valid in local storage to get it to actually work looking at the protected component you can see that what this is doing when we click visit that route so ng on init so when this component is loaded the first thing that it will do is make a get request to this link right here which on our express application as you saw in the last video is only going to allow users to receive the correct data if they are authenticated with a jwt that the express server deems as valid right here is the protected route and if we are not authenticating correctly if our if we don't have a jwt attached to this get request or the jwt is invalid we should receive a 401 unauthorized error if we are valid then we should receive this message right here so here's the message you are authorized okay so let's close this out go back to the protected component and you'll see that if we get a response we're going to print the message attached that response so we should see what we were just looking at in the express application if it was successful but if we have an error which is going to be a status of 401 or unauthorized the message is going to be you are not authorized to visit this route and we saw that earlier in the browser so let's go solve the last piece of the puzzle open up the auth interceptor which right now is empty i'm going to paste in the implementation here and then we're going to walk through it so let me indent this correctly okay so again this is not an angular tutorial you're going to have to read up on interceptors which you can find on their documentation it gives you a lot of examples but basically what this is doing is kind of intercepting every http request that angular is sending out and it's going to attach or it's going to run the intercept method so what we're doing here is first we're grabbing this should not be id token should be just token we're grabbing the token from local storage and then if there is an id token so if we get a token from local storage then so far we're good what we're going to do is clone the request so we're taking the current request that is going through the chain of interceptors it's kind of like middleware and express almost and we're going to take that and clone it but this time we're going to set the authorization header equal to the id token so that should set authorate authorization header equal to bearer and then a space and then the jwt then we say return next dot handle and pass in that cloned object so that should basically right here that should successfully attach the jwt if we don't find a token which is very possible if the user is not logged in then we just return next.handle the request and there's going to be no authorization header whatsoever we now have an auth interceptor which should attach this jwt token to our request now if we go to the browser to our application technically if we visit this protected route right now it should say that we are authorized because you remember we already logged in and you'll see that we have the token and the expires already in the browser so as long as we attach this to our next request it should authenticate us so let's try that if you remember from the last request there was no author authorization header but now if we visit the protected route it says you are authorized and if we go to the network tab this is a little bit tricky you're probably tempted to click on localhost but we need to click on protected and you'll see that down in the request headers there is this authorization header which has the jwt that we had stored in local storage so that is the basic flow and you can use this concept to basically manage your users within an angular application and obviously there could be users with different types of permissions and that would require you to come back to your interceptor and write in some custom logic to say okay hey based on what role this user has are we going to attach you know the jwt or not and also you might be you might have routes on the express application that may or may not require authentication but hopefully this implementation so the combination of this auth interceptor and the off service hopefully those two things along with the previous video where we talked about how do we actually issue that jwt have brought your understanding of user authentication um you know to a conclusion and hopefully this all makes sense this is just one way that we can implement user authentication in our front end or angular app you're going to see a lot of different implementations across a lot of different coding languages the most important thing is to understand how everything works how does the jwt work and how are we supposed to kind of pass it from the front end to the back end once you understand that it should be a breeze to implement your own authentication strategy you never thought that we'd make it to this point but we're here we're at the end of this super long user authentication crash course and i want to say a big thank you if you watched all the way through that's really an accomplishment to get through you know however many hours this took us to understand all these concepts and if you are one of those crazy people that went from the very beginning of this uh course all the way to the end here and didn't skip anything i'd love to hear from you i'm on twitter at zg underscore dev and i'd really love to hear from you so reach out tell me what you thought about this course or just say hi once again i'd really appreciate if you checked out my much smaller youtube channel and just gave it a look and until next time i will see you later\n"