1 00:00:00,150 --> 00:00:06,450 You know have an H2 T.P. request for logging in and you're validating the credentials that are provided 2 00:00:06,450 --> 00:00:10,110 which is a great start in this video we're going to continue on. 3 00:00:10,350 --> 00:00:17,520 And we're actually going to allow users to truly log in so they can perform other actions later on like 4 00:00:17,520 --> 00:00:19,470 creating a new task. 5 00:00:19,560 --> 00:00:26,400 So in the end of the day every single express route we define will fall into one of two categories. 6 00:00:26,430 --> 00:00:33,180 It'll either be public and accessible to anyone or it sit behind authentication and you'll have to be 7 00:00:33,180 --> 00:00:35,850 correctly authenticated to use it. 8 00:00:35,850 --> 00:00:42,120 Now the only two routes that are going to be public will be these sign up route and the log in route 9 00:00:42,390 --> 00:00:49,440 everything else whether it's related to users or tasks is going to require you to be authenticated. 10 00:00:49,440 --> 00:00:55,950 For example if you're trying to delete a task I need you to be authenticated so I can make sure that 11 00:00:55,950 --> 00:00:57,570 you are the one to create it. 12 00:00:57,780 --> 00:01:02,700 I don't want you to be able to delete a task created by some other user. 13 00:01:02,700 --> 00:01:08,610 What we need to do is set up the log in request to send back and authentication token. 14 00:01:08,700 --> 00:01:14,400 This is something that the requester will be able to use later on with other requests where they need 15 00:01:14,400 --> 00:01:15,870 to be authenticated. 16 00:01:15,960 --> 00:01:22,410 So I could log in with my account I'd get the token back then I could go off and edit my user profile 17 00:01:22,530 --> 00:01:25,810 or do something else like create a new task. 18 00:01:25,860 --> 00:01:30,840 So the goal of this video is to figure out how we're going to create and manage those authentication 19 00:01:30,840 --> 00:01:31,890 tokens. 20 00:01:31,960 --> 00:01:39,510 What we'll be using in this course is what's known as a Jason web token or JWT for short. 21 00:01:39,510 --> 00:01:42,840 The Jason web token standard is very popular. 22 00:01:42,870 --> 00:01:49,630 It can be used for all sorts of things including authentication and with J W TS we'll be able to set 23 00:01:49,630 --> 00:01:53,220 up everything we want for our little authentication system. 24 00:01:53,220 --> 00:01:59,790 For example we'll be able to do things like have tokens expire after a certain amount of time so users 25 00:01:59,790 --> 00:02:06,330 can't stay logged in for ever optionally we could never expire the token and allow a user to use it 26 00:02:06,390 --> 00:02:07,830 indefinitely. 27 00:02:07,830 --> 00:02:14,190 So let's go ahead and talk more about Jason Webb tokens or J.W. TS as I'll call them here and there 28 00:02:14,610 --> 00:02:21,210 and to start we'll explore the library we're going to use which allows us to work with JWT ts in node 29 00:02:21,240 --> 00:02:24,040 j s over in the browser. 30 00:02:24,060 --> 00:02:32,340 What I'm gonna do is Google NPM Jason Webb token as one word and that is the package we're looking for. 31 00:02:32,370 --> 00:02:39,990 The Jason Webb token library this provides us everything we need for creating these authentication tokens 32 00:02:40,170 --> 00:02:47,040 and validating them making sure they are still valid for example making sure they haven't expired. 33 00:02:47,040 --> 00:02:53,430 This is a super popular package with over a million weekly downloads and we're going to start by integrating 34 00:02:53,430 --> 00:03:01,320 it into our application in index dot J s much like we did with B script J S once we understand how it 35 00:03:01,320 --> 00:03:04,840 works will integrate it into the task manager app. 36 00:03:05,010 --> 00:03:11,010 So down below in the terminal let's go ahead and get started by installing things I'll use control C 37 00:03:11,010 --> 00:03:20,820 to shut down the dev server and from here NPM I Jason Webb token at the latest version which is eight 38 00:03:21,060 --> 00:03:23,350 point four point zero. 39 00:03:23,370 --> 00:03:28,650 Let's go ahead and get that installed and once it's installed I'm just gonna start up the dev server 40 00:03:28,680 --> 00:03:33,000 once again and we'll mess around with it in my function over here. 41 00:03:33,000 --> 00:03:37,440 Let's start up the dev server that's NPM run Dev. 42 00:03:37,440 --> 00:03:43,920 And once we have that in place I'm going to clear the contents of my function and I'm going to swap 43 00:03:43,920 --> 00:03:48,210 out the old require call with a new one right here. 44 00:03:48,300 --> 00:03:56,520 Let's go ahead and create a new constant called JWT and we will get its value by requiring the following 45 00:03:56,580 --> 00:04:00,780 the Jason Webb token library down below. 46 00:04:00,780 --> 00:04:06,000 We're going to explore how we can create authentication tokens and how we can validate them. 47 00:04:06,090 --> 00:04:10,050 Then we'll integrate it into the app to create a new Jason Webb token. 48 00:04:10,050 --> 00:04:16,760 We'll be using the sign method available on JWT that is JWT dot sign. 49 00:04:16,830 --> 00:04:20,860 Now sign does indeed take some arguments which we'll talk about in a second. 50 00:04:20,970 --> 00:04:24,310 And the return value from sign is your new token. 51 00:04:24,330 --> 00:04:31,110 In our case our authentication token this token will be provided to the client and then they can use 52 00:04:31,110 --> 00:04:36,730 the token later on to perform those privileged operations like creating a task. 53 00:04:36,750 --> 00:04:43,170 So right here let's take a quick moment to create a variable to store the token that sine returns. 54 00:04:43,200 --> 00:04:46,260 Now these sine function itself takes two arguments. 55 00:04:46,260 --> 00:04:50,520 The first is an object and the second is a string. 56 00:04:50,520 --> 00:04:55,110 The object contains the data that's going to be embedded in your token. 57 00:04:55,110 --> 00:04:58,920 Now for us using JWT is for authentication. 58 00:04:58,920 --> 00:05:04,980 The only thing we really need to store inside of here is a unique identifier for the user who's being 59 00:05:04,980 --> 00:05:05,850 authenticated. 60 00:05:05,850 --> 00:05:09,540 In this case the user's I.D. works perfectly. 61 00:05:09,660 --> 00:05:14,380 So the only property will set up on our payload is underscore I.D.. 62 00:05:14,520 --> 00:05:20,340 And I'll set the value equal to a dummy I.D. for the moment though later on it'll be the user's real 63 00:05:20,340 --> 00:05:23,040 I.D. stored in the database. 64 00:05:23,040 --> 00:05:28,390 So that is it for the first argument we could provide other pieces of information if we needed to. 65 00:05:28,440 --> 00:05:32,050 But the I.D. gets the job done for our purposes. 66 00:05:32,070 --> 00:05:34,910 Now that second argument this is a secret. 67 00:05:34,950 --> 00:05:41,190 This is gonna be used to sign the token making sure that it hasn't been tampered with or altered in 68 00:05:41,190 --> 00:05:41,910 any way. 69 00:05:42,270 --> 00:05:47,650 All we need to do for this one is provide a random series of characters. 70 00:05:47,700 --> 00:05:52,900 I'll just use a sentence like this is my new course. 71 00:05:52,920 --> 00:05:55,170 Any series of characters will work. 72 00:05:55,650 --> 00:06:02,130 So what we get back from sine that is the token will end up giving back to the user who's trying to 73 00:06:02,130 --> 00:06:03,200 log in. 74 00:06:03,240 --> 00:06:08,190 Let's take a quick moment to log it to the council and see what we get right here. 75 00:06:08,190 --> 00:06:15,000 I'll be logging the token and then saving the program so our little function reruns and down below we 76 00:06:15,000 --> 00:06:18,010 have a nice long series of characters. 77 00:06:18,030 --> 00:06:25,380 This is our Jason Webb token now the Jason Webb token is actually made up of three distinct parts separated 78 00:06:25,380 --> 00:06:26,440 by the period. 79 00:06:26,460 --> 00:06:29,910 So I have two periods one here and one over here. 80 00:06:29,910 --> 00:06:33,330 That means this is the first piece of the Jason Webb token. 81 00:06:33,660 --> 00:06:37,450 This is a base64 encoded Jason string. 82 00:06:37,560 --> 00:06:39,270 And this is known as the header. 83 00:06:39,390 --> 00:06:43,050 It contains some meta information about what type of token it is. 84 00:06:43,050 --> 00:06:47,690 It's a JWT and the algorithm that was used to generate it. 85 00:06:47,730 --> 00:06:50,340 The second piece in between the two periods. 86 00:06:50,430 --> 00:06:53,370 This is known as the payload or body. 87 00:06:53,370 --> 00:06:57,960 This is also a base64 encoded Jason string. 88 00:06:57,960 --> 00:07:03,830 And this contains the data that we provided which in our case would be the I.D. from up above. 89 00:07:03,840 --> 00:07:09,990 After that last period to the very end of the Jason Webb token we have the signature. 90 00:07:09,990 --> 00:07:14,130 And this is used to verify the token later on when we verify it. 91 00:07:14,130 --> 00:07:15,720 We'll see how that comes into play. 92 00:07:16,320 --> 00:07:21,980 So the goal of the Jason Webb token isn't to hide the data that you've provided right here. 93 00:07:21,990 --> 00:07:27,510 This is actually publicly viewable to anyone who has the token they don't need the secret to see that 94 00:07:27,960 --> 00:07:31,480 the whole point of the JWT is to create data. 95 00:07:31,560 --> 00:07:35,490 This data that's verifiable via these signature. 96 00:07:35,490 --> 00:07:40,500 So if someone else comes along and tries to change the data right here they're not going to be able 97 00:07:40,500 --> 00:07:46,800 to do so successfully because they won't know what secret was used with the algorithm so things will 98 00:07:46,800 --> 00:07:49,160 fail to prove this real quick. 99 00:07:49,170 --> 00:07:55,250 Take a moment to copy that middle value so whatever you have between those two periods and we're going 100 00:07:55,250 --> 00:08:02,490 to head over to the browser and we're going to go to base 64 decode dot org. 101 00:08:02,490 --> 00:08:07,950 Now there's ways in programming languages where you can get this done but for this little example we 102 00:08:07,950 --> 00:08:13,230 can just paste it in this box click decode and what do we see down below. 103 00:08:13,230 --> 00:08:17,940 We see some Jason we have a Jason object with two values. 104 00:08:17,940 --> 00:08:21,320 We have the one we provided underscore I.D.. 105 00:08:21,630 --> 00:08:29,340 ABC 1 2 3 being the value then we have AI 80 which stands for issued at. 106 00:08:29,380 --> 00:08:33,300 And this is a timestamp letting you know when the token was created. 107 00:08:33,300 --> 00:08:38,910 So this is exactly what's embedded in the part of the Jason web token right here. 108 00:08:38,910 --> 00:08:44,340 Now that we've seen how we can create a token let's talk about how we can verify our tokens. 109 00:08:44,580 --> 00:08:51,090 So back over in visual studio code what we're going to do is use that token and actually try to verify 110 00:08:51,090 --> 00:08:56,390 it by running a another function that the Jason Webb token library provides. 111 00:08:56,400 --> 00:09:02,700 This is JWT dot verify verify takes two arguments. 112 00:09:02,700 --> 00:09:06,060 The first is the token you're trying to verify. 113 00:09:06,060 --> 00:09:08,370 And the second is the secret to use. 114 00:09:08,370 --> 00:09:14,620 Now in this case I need to use the exact same secret that the token was created with. 115 00:09:14,700 --> 00:09:19,110 So I will take these string from up above and I will paste it down below. 116 00:09:19,110 --> 00:09:23,520 Later on in the course you'll learn how to break this out into an environment variable. 117 00:09:23,520 --> 00:09:27,660 But for now having these strings in line is perfectly fine. 118 00:09:27,750 --> 00:09:33,020 Now verify is going to return the payload for the token if things went well. 119 00:09:33,030 --> 00:09:34,770 And the token is valid. 120 00:09:34,830 --> 00:09:37,590 Otherwise it's going to go ahead and throw an error. 121 00:09:37,650 --> 00:09:42,540 So right here const data equals then down below. 122 00:09:42,540 --> 00:09:47,300 I'll just use console dot log to dump the data to the terminal. 123 00:09:47,310 --> 00:09:50,750 Now in this case the verification should work and down below. 124 00:09:50,760 --> 00:09:52,530 That's exactly what's happening. 125 00:09:52,560 --> 00:09:56,080 We run verify and we get our data back. 126 00:09:56,100 --> 00:09:59,000 Now let's see what happens if things don't work. 127 00:09:59,010 --> 00:10:04,460 If I mess these secret up and put to ease on the end in one case but not in the other. 128 00:10:04,480 --> 00:10:11,310 I get a whole bunch of stuff down below in the terminal and the error up above is un handled promise 129 00:10:11,320 --> 00:10:16,450 rejection warning Jason Webb token error Invalid signature. 130 00:10:16,480 --> 00:10:21,850 So this is letting me know that the token couldn't be verified based on the input we provided. 131 00:10:21,850 --> 00:10:29,960 These secret needs to be the same for both now one more thing we can do with Jason Webb tokens is expire 132 00:10:29,960 --> 00:10:35,600 them after a certain amount of time which can be a really useful thing to do this when we create the 133 00:10:35,600 --> 00:10:36,350 token. 134 00:10:36,350 --> 00:10:42,040 We provide a third argument an object where we can customize it with some options. 135 00:10:42,050 --> 00:10:51,410 One option is expires in expires in allows you to provide as a string the amount of time you want your 136 00:10:51,410 --> 00:10:52,840 token to be valid. 137 00:10:52,850 --> 00:11:01,040 So for example I could type in seven days as a plain English sentence or something like two weeks or 138 00:11:01,040 --> 00:11:02,320 one month. 139 00:11:02,330 --> 00:11:04,840 In our case let's go ahead and expire. 140 00:11:04,850 --> 00:11:07,580 Our token after one second. 141 00:11:07,580 --> 00:11:09,980 Actually let's go ahead and make it shorter. 142 00:11:09,980 --> 00:11:11,360 Zero seconds. 143 00:11:11,390 --> 00:11:15,300 So the token is technically never not expired. 144 00:11:15,410 --> 00:11:20,190 If I go ahead and actually run the program down below what are we going to see. 145 00:11:20,240 --> 00:11:21,610 We're going to see an error. 146 00:11:21,620 --> 00:11:27,340 The JWT has expired since the token is never not expired. 147 00:11:27,350 --> 00:11:34,220 Now if I were to crank that up to a more realistic value like seven days things would work as expected 148 00:11:34,370 --> 00:11:40,450 because seven days do not pass between when this code and this code run it's a fraction of a second 149 00:11:40,490 --> 00:11:44,060 and down below we can see that things are still working. 150 00:11:44,120 --> 00:11:45,430 So here's what we're gonna do. 151 00:11:45,560 --> 00:11:49,710 We'll use JWT signed to create authentication tokens. 152 00:11:49,760 --> 00:11:56,450 Then later on we'll use JWT dot verify to make sure the user is authenticated correctly. 153 00:11:56,450 --> 00:12:02,600 Let's go ahead and stop here for this one and we'll integrate J.W. TS into the task manager app in the 154 00:12:02,600 --> 00:12:03,140 next one.