1 00:00:03,890 --> 00:00:11,670 Now that we have understood the token based authentication using the JSON Web Tokens, 2 00:00:11,670 --> 00:00:16,035 and also understood the advantages of using this approach. 3 00:00:16,035 --> 00:00:22,185 The fact that we are now building a Rest API based server, 4 00:00:22,185 --> 00:00:24,420 in this course means 5 00:00:24,420 --> 00:00:27,585 the JSON Web Token based authentication 6 00:00:27,585 --> 00:00:31,410 is most suited for this server that we are building. 7 00:00:31,410 --> 00:00:40,585 So, let's update our Rest API server to make use of JSON Web Tokens in this exercise. 8 00:00:40,585 --> 00:00:45,755 To begin updating the server at your terminal, 9 00:00:45,755 --> 00:00:51,935 let's first install the JSON Web Token and the passport JWT Node module. 10 00:00:51,935 --> 00:00:56,445 So, at the prompt type npm, install, 11 00:00:56,445 --> 00:01:05,640 passport JWT JSON Web Token and minus minus save. 12 00:01:05,640 --> 00:01:15,435 As you can see, I'm using JSON Web Token 8.3.0 and passport JWT 4.0.0 in this course. 13 00:01:15,435 --> 00:01:23,180 Now that we have completed the installation let's go ahead and update our express server. 14 00:01:23,180 --> 00:01:25,700 Going now to our code, 15 00:01:25,700 --> 00:01:30,289 let's add in a file named 16 00:01:30,289 --> 00:01:36,335 conflict.js in the root folder of our project. 17 00:01:36,335 --> 00:01:39,455 Now, this conflict.js file I'm going to use it 18 00:01:39,455 --> 00:01:43,220 to store some configuration information for our server. 19 00:01:43,220 --> 00:01:49,790 Now, this is a way of centralizing all the configuration for our server. 20 00:01:49,790 --> 00:01:53,600 In this conflict.js file, 21 00:01:53,600 --> 00:01:59,825 let me export a JSON object here. 22 00:01:59,825 --> 00:02:02,490 So we'll say, secretKey, 23 00:02:08,510 --> 00:02:11,550 and this is where 24 00:02:19,450 --> 00:02:28,705 I will specify the secret key that I'm going to be using for signing my JSON Web Token, 25 00:02:28,705 --> 00:02:36,700 and also let me specify a Mongo URL here, 26 00:02:36,700 --> 00:02:41,275 which will be the URL for 27 00:02:41,275 --> 00:02:51,710 my MongoDB server localhost 27017. 28 00:02:52,200 --> 00:02:55,060 Once we have completed that, 29 00:02:55,060 --> 00:02:59,260 then we will go to authenticate.js file, 30 00:02:59,260 --> 00:03:01,780 and in authenticate.js file we will 31 00:03:01,780 --> 00:03:10,700 now create the JWT strategy. 32 00:03:11,250 --> 00:03:16,175 This is the JSON web token strategy which is provided by 33 00:03:16,175 --> 00:03:25,830 our passport JWT node module that we have just included and so we'll say, 34 00:03:26,300 --> 00:03:32,895 generativity strategy passport generativity.strategy. 35 00:03:32,895 --> 00:03:35,370 This will provide us with 36 00:03:35,370 --> 00:03:40,550 a JSON Web Token based strategy for configuring our passport module, 37 00:03:40,550 --> 00:03:46,820 then extract JWT, which I 38 00:03:46,820 --> 00:03:53,745 will also get from passport JWT. 39 00:03:53,745 --> 00:03:55,935 We'll require passport JWT, 40 00:03:55,935 --> 00:03:59,565 then we'll say "Extract JWT." 41 00:03:59,565 --> 00:04:02,655 Then let's import 42 00:04:02,655 --> 00:04:10,240 the JSON Web Token module 43 00:04:10,240 --> 00:04:12,265 that we just installed. 44 00:04:12,265 --> 00:04:15,340 Once we have imported these, 45 00:04:15,340 --> 00:04:18,370 let's go ahead and start configuring a few things. 46 00:04:18,370 --> 00:04:26,205 Along with these, let me import the config that I have 47 00:04:26,205 --> 00:04:35,840 created the config.js file that I've just added to my project. 48 00:04:35,840 --> 00:04:40,100 Once I complete this then let me go ahead and 49 00:04:40,100 --> 00:04:45,650 introduce a few additional functions which I will export from here. 50 00:04:45,650 --> 00:04:49,200 We'll say, exports.getToken, 51 00:04:55,160 --> 00:05:02,840 this function when supply with a parameter there which I will simply call user, 52 00:05:02,840 --> 00:05:06,335 which will be a JSON object, 53 00:05:06,335 --> 00:05:10,145 this will create the token and give it for us. 54 00:05:10,145 --> 00:05:16,685 To create the token, we will be using the jsonwebtoken module that we just imported. 55 00:05:16,685 --> 00:05:22,140 So, here we'll say return JWT.sign, 56 00:05:23,750 --> 00:05:31,355 this helps us to create the JSON Web Token and so inside that it'll 57 00:05:31,355 --> 00:05:34,430 allow me to supply the payload and 58 00:05:34,430 --> 00:05:38,825 the payload here comes in as the parameter here called user, 59 00:05:38,825 --> 00:05:42,620 and then the second parameter is 60 00:05:42,620 --> 00:05:51,050 the secret or private key which I get from config.secret key, 61 00:05:51,050 --> 00:05:55,260 which I have just configured a little bit earlier. 62 00:05:55,630 --> 00:06:02,835 We can supply additional options here. 63 00:06:02,835 --> 00:06:07,055 One option that I'm going to supply to this is-. 64 00:06:07,055 --> 00:06:09,410 Okay, let me go to the next line here, 65 00:06:09,410 --> 00:06:14,160 the option that I will supply is expiresIn. 66 00:06:14,530 --> 00:06:20,945 The expiresIn will tell you how long the jsonwebtoken will be 67 00:06:20,945 --> 00:06:27,185 valid so in this case I say 3,600 meaning 3,600 seconds or about an hour. 68 00:06:27,185 --> 00:06:32,825 An hour later you will have to renew the jsonwebtoken. 69 00:06:32,825 --> 00:06:36,790 An hour is long enough for us to be able to test our application. 70 00:06:36,790 --> 00:06:40,370 You can set this to be much longer if you choose to. 71 00:06:40,370 --> 00:06:45,110 In a real application you might set this to be a much longer value maybe 72 00:06:45,110 --> 00:06:50,075 a few days and expect the user to re-authenticate themselves every few days. 73 00:06:50,075 --> 00:06:52,670 Now, we will also next configure 74 00:06:52,670 --> 00:06:58,025 the jsonwebtoken based strategy for our passport application. 75 00:06:58,025 --> 00:07:02,900 So, let me declare a variable called opts, 76 00:07:02,900 --> 00:07:12,140 which is nothing but the options that I'm going to specify for my JWT based strategy. 77 00:07:12,140 --> 00:07:18,905 So we'll say opts JWTfromrequest. 78 00:07:18,905 --> 00:07:22,925 Now this option specifies 79 00:07:22,925 --> 00:07:28,580 how the jsonwebtoken should be extracted from the incoming request message. 80 00:07:28,580 --> 00:07:33,755 This is where we will use the extract JWT. 81 00:07:33,755 --> 00:07:39,290 This extract JWT supports various methods 82 00:07:39,290 --> 00:07:44,970 for extracting information from the header. 83 00:07:44,970 --> 00:07:49,580 It'll say from authHeader from authHeader as bearer token, 84 00:07:49,580 --> 00:07:51,510 from header which scheme and so on. 85 00:07:51,510 --> 00:07:54,380 If you read the documentation it will tell 86 00:07:54,380 --> 00:07:58,040 you various ways of extracting the jsonwebtoken. 87 00:07:58,040 --> 00:08:00,770 You can pass the token in the body of 88 00:08:00,770 --> 00:08:04,970 the incoming request message and then you can extract it from there, 89 00:08:04,970 --> 00:08:08,255 you can also use custom extractors and so on. 90 00:08:08,255 --> 00:08:14,180 In this course, I'm going to use the simplest method called 91 00:08:14,180 --> 00:08:20,745 from authentication header as a bearer token. 92 00:08:20,745 --> 00:08:22,220 We are already familiar with 93 00:08:22,220 --> 00:08:25,055 the Authentication Header because as we have been using that with 94 00:08:25,055 --> 00:08:30,440 the basic authentication and the cookie-based authentication earlier. 95 00:08:30,440 --> 00:08:32,180 So, I'm just going to use 96 00:08:32,180 --> 00:08:38,350 that same header field in the request message to carry the jsonwebtoken. 97 00:08:38,350 --> 00:08:45,270 So I'll say opts as bearer token jsonwebtoken. 98 00:08:45,270 --> 00:08:51,160 The next one we'll say opts.secretOrKey, 99 00:08:56,980 --> 00:09:02,795 this is the second parameter which helps me to 100 00:09:02,795 --> 00:09:11,670 supply the secret key which I'm going to be using within my strategy for the sign-in. 101 00:09:11,670 --> 00:09:15,875 So that is the other option that I'm going to specify here. 102 00:09:15,875 --> 00:09:18,065 Once I'm specifying these two, 103 00:09:18,065 --> 00:09:26,390 let me export the Passport strategy 104 00:09:26,390 --> 00:09:30,680 which I'm going to configure here so we'll say exportJWTpassport, 105 00:09:30,680 --> 00:09:34,355 then we'll say passport.use. 106 00:09:34,355 --> 00:09:37,940 Recall the way you specified the local strategy earlier. 107 00:09:37,940 --> 00:09:42,035 Here we are specifying the JWT based strategy, 108 00:09:42,035 --> 00:09:47,895 then we will create a new JWT strategy, 109 00:09:47,895 --> 00:09:51,320 recall that we just imported the JWT strategy 110 00:09:51,320 --> 00:09:56,615 here that is what we will use to create a new strategy. 111 00:09:56,615 --> 00:10:01,235 This JWT strategy takes 112 00:10:01,235 --> 00:10:07,675 the options object that I just created as the first parameter. 113 00:10:07,675 --> 00:10:14,210 The strategy options and the second one is the verify function that I need to supply, 114 00:10:14,210 --> 00:10:18,050 and so the verify function I'm going to supply it in the next line here, 115 00:10:18,050 --> 00:10:28,545 we'll say functionJWT_payload. 116 00:10:28,545 --> 00:10:33,900 Done. So, when this function is called, 117 00:10:33,900 --> 00:10:39,270 the done is the callback that is provided by passport. 118 00:10:39,270 --> 00:10:44,270 So, whenever you have passport which you're configuring with a new strategy, 119 00:10:44,270 --> 00:10:46,750 you need to supply the second parameter done. 120 00:10:46,750 --> 00:10:48,460 Through this done parameter, 121 00:10:48,460 --> 00:10:52,235 you will be passing back information to passport which it will then 122 00:10:52,235 --> 00:10:57,780 use for loading things onto the request message. 123 00:10:57,780 --> 00:11:00,710 So, when passport parses the request message, 124 00:11:00,710 --> 00:11:04,110 it will use the strategy and then extract information, 125 00:11:04,110 --> 00:11:09,540 and then load it onto our request message. 126 00:11:09,540 --> 00:11:13,905 So, since this happens to be a function, 127 00:11:13,905 --> 00:11:19,795 I'm just going to use a arrow function here, 128 00:11:19,795 --> 00:11:22,160 I've gotten fond of arrow functions. 129 00:11:22,160 --> 00:11:25,650 So, let me create that as an arrow function here, 130 00:11:25,650 --> 00:11:28,345 and inside of this function, 131 00:11:28,345 --> 00:11:30,465 we will be defining the function. 132 00:11:30,465 --> 00:11:32,970 So, what do we do inside the function? 133 00:11:32,970 --> 00:11:37,420 Let me do a console.log of 134 00:11:38,370 --> 00:11:44,020 JWT payload and then 135 00:11:44,660 --> 00:11:49,995 let me just log out the option coming in here, 136 00:11:49,995 --> 00:11:51,770 the JWT payload Option coming here, 137 00:11:51,770 --> 00:11:55,420 so that you can see what is inside the JWT payload. 138 00:11:55,420 --> 00:12:04,250 Then, we will search for a user by saying User.findOne, 139 00:12:04,250 --> 00:12:14,020 and then I know that in the jwt.payload, 140 00:12:14,020 --> 00:12:17,210 there is a ID field that comes in. 141 00:12:17,210 --> 00:12:21,360 So, that is what I am going to be assigning as the ID field here. 142 00:12:21,360 --> 00:12:26,040 So, I will say, User.findOne and the second one 143 00:12:26,040 --> 00:12:36,190 is a callback function. 144 00:12:36,870 --> 00:12:45,295 As you realize, this user Mongoose method and you try to find. 145 00:12:45,295 --> 00:12:54,665 So, we'll say if err then, return done. 146 00:12:54,665 --> 00:12:57,945 What does this done? This done is the callback that 147 00:12:57,945 --> 00:13:02,155 passport will pass into your strategy here. 148 00:13:02,155 --> 00:13:04,965 So, we are going to be calling this done function. 149 00:13:04,965 --> 00:13:11,200 This done in passport takes three parameters. 150 00:13:12,890 --> 00:13:20,400 So, you can see the three pieces of information this done expects it says, error: any. 151 00:13:20,400 --> 00:13:24,525 So, if you have an error you will pass it in as the first parameter. 152 00:13:24,525 --> 00:13:26,495 The second parameter, user?, 153 00:13:26,495 --> 00:13:28,245 If a user exists, 154 00:13:28,245 --> 00:13:33,770 then the user value will be passed in and then if any info?:, any. 155 00:13:33,770 --> 00:13:37,100 So, these two are optional parameters and so, 156 00:13:37,100 --> 00:13:38,690 if you pass in any information, 157 00:13:38,690 --> 00:13:42,145 then that will be used within the application. 158 00:13:42,145 --> 00:13:44,650 If I pass in false as the second parameter, 159 00:13:44,650 --> 00:13:47,515 then that means that the user doesn't exist or that. 160 00:13:47,515 --> 00:13:50,810 So, it'll interpret that the user doesn't exist. 161 00:13:50,810 --> 00:13:52,335 So, I could say, err, 162 00:13:52,335 --> 00:13:54,900 false, because this is an error. 163 00:13:54,900 --> 00:13:58,080 So, I'm not going to be passing in a user value there, 164 00:13:58,080 --> 00:14:00,660 I'm just going to pass in false. 165 00:14:00,660 --> 00:14:06,040 There, the next, 166 00:14:06,040 --> 00:14:11,510 we can say, else if (user). 167 00:14:11,510 --> 00:14:15,860 So, if the user is not null, 168 00:14:15,860 --> 00:14:18,960 we'll say return done(null). 169 00:14:19,230 --> 00:14:22,210 There is no error so, the first parameter will be 170 00:14:22,210 --> 00:14:25,080 null and the second parameter is the user, 171 00:14:25,080 --> 00:14:29,895 but we just got from the MongoDB. 172 00:14:29,895 --> 00:14:35,445 Otherwise, we will return 173 00:14:35,445 --> 00:14:41,395 done with null, false. 174 00:14:41,395 --> 00:14:43,650 So, in the last case, 175 00:14:43,650 --> 00:14:45,100 we could not find the user, 176 00:14:45,100 --> 00:14:47,120 so we're going to be passing in false. 177 00:14:47,120 --> 00:14:50,200 So, we're going to be handling it like this. 178 00:14:50,200 --> 00:14:53,345 If you want, you can create a new user account at this point 179 00:14:53,345 --> 00:14:58,365 but I'm going to keep this simple just so that it's easy for us to understand. 180 00:14:58,365 --> 00:15:00,810 So, we'll just say, null, false. That's six. 181 00:15:00,810 --> 00:15:07,475 So, this is the JsonWebToken passport strategy that I've just configured here. 182 00:15:07,475 --> 00:15:11,420 Also, let me export 183 00:15:11,420 --> 00:15:19,450 one more function from here called verifyUser. 184 00:15:19,450 --> 00:15:21,110 Now, this verifyUser function, 185 00:15:21,110 --> 00:15:24,935 I'm going to be using it to verify an incoming user. 186 00:15:24,935 --> 00:15:28,810 So, this is where I will use passport.authenticate. 187 00:15:28,890 --> 00:15:36,440 So, the passport.authenticate, the strategy is jwt strategy which I've just configured, 188 00:15:36,440 --> 00:15:39,490 the JsonWebToken strategy that I've just configured. 189 00:15:39,490 --> 00:15:41,625 Then, the second part, 190 00:15:41,625 --> 00:15:46,305 I would say, session: false. 191 00:15:46,305 --> 00:15:47,740 So, that means that, 192 00:15:47,740 --> 00:15:51,305 we are not going to be creating sessions in this case. 193 00:15:51,305 --> 00:15:58,215 As you recall, a inverse application, 194 00:15:58,215 --> 00:16:00,530 we are using token-based authentication. 195 00:16:00,530 --> 00:16:02,435 So we're not going to be creating sessions. 196 00:16:02,435 --> 00:16:07,690 So, that's why I set this option session to false here, 197 00:16:07,690 --> 00:16:11,795 and of course, the first one specified the strategy that I'm going to be using. 198 00:16:11,795 --> 00:16:14,050 So, for verifying a user, 199 00:16:14,050 --> 00:16:15,930 I will use the JWT strategy. 200 00:16:15,930 --> 00:16:18,110 How does the JWT strategy work? 201 00:16:18,110 --> 00:16:20,540 In the incoming request, 202 00:16:21,040 --> 00:16:26,845 the token will be included in the authentication header as we saw here. 203 00:16:26,845 --> 00:16:29,950 We said authentication header as bearer token. 204 00:16:29,950 --> 00:16:33,530 If that is included, then that'll be extracted and that will be 205 00:16:33,530 --> 00:16:38,210 used to authenticate the user based upon the token. 206 00:16:38,210 --> 00:16:47,770 Minor correction here, this should be User.findOne_id is equal to jwt_payload._id, 207 00:16:47,770 --> 00:16:56,475 because that is the id value that is inside the payload of my JsonWebToken. 208 00:16:56,475 --> 00:17:01,615 So, we are searching for the user with that given ID. 209 00:17:01,615 --> 00:17:06,170 So, once we have completed this, then now, 210 00:17:06,170 --> 00:17:11,790 the second part that we need to do is that we need to create the token somewhere. 211 00:17:11,790 --> 00:17:14,005 Now, where do we create the token? 212 00:17:14,005 --> 00:17:20,290 So, this is where something that we are doing in the users.js file is very useful for us. 213 00:17:20,290 --> 00:17:22,270 In the users.js file, 214 00:17:22,270 --> 00:17:27,180 recall that you already have this endpoint called login. 215 00:17:27,180 --> 00:17:28,700 In the login endpoint, 216 00:17:28,700 --> 00:17:33,410 you were using the username and password to authenticate the user. 217 00:17:33,410 --> 00:17:38,030 So, even with the JsonWebToken to issue the JsonWebToken, 218 00:17:38,030 --> 00:17:41,959 you first need to authenticate the user using one of the other strategies, 219 00:17:41,959 --> 00:17:44,630 and if you're going to be using the local strategy first, 220 00:17:44,630 --> 00:17:49,715 we will authenticate the user using the username and password. 221 00:17:49,715 --> 00:17:53,415 Once the user is authenticated with the username and password, 222 00:17:53,415 --> 00:17:55,885 then we will issue the token to the user saying, 223 00:17:55,885 --> 00:17:57,330 "Okay, you are a valid user, 224 00:17:57,330 --> 00:17:58,630 I'm going to give you the token". 225 00:17:58,630 --> 00:18:02,390 All of the subsequent requests will simply carry the token 226 00:18:02,390 --> 00:18:06,860 in the header of the incoming request message. 227 00:18:06,860 --> 00:18:10,415 So, earlier, we used to create sessions. 228 00:18:10,415 --> 00:18:11,840 When the user is authenticated, 229 00:18:11,840 --> 00:18:13,935 we're not going to be using sessions anymore. 230 00:18:13,935 --> 00:18:17,640 Instead, when the user is authenticated using the local strategy, 231 00:18:17,640 --> 00:18:20,110 we will issue a token to the user. 232 00:18:20,110 --> 00:18:25,955 So, inside this router.POST method that we have done on that /login endpoint, 233 00:18:25,955 --> 00:18:31,730 I'm going to create a token and pass this token back to the user. 234 00:18:31,730 --> 00:18:36,980 So, in here, we will say a router.POST. 235 00:18:38,550 --> 00:18:40,785 Let me create a token. 236 00:18:40,785 --> 00:18:42,630 To create a token, 237 00:18:42,630 --> 00:18:50,150 we have this function in the authenticate module called authenticate.getToken. 238 00:18:51,250 --> 00:18:54,325 So, recall, that we have already, 239 00:18:54,325 --> 00:18:57,050 to make use of that of course, 240 00:18:57,050 --> 00:18:59,210 even before we start there, 241 00:18:59,210 --> 00:19:02,750 I need to import the authenticate. 242 00:19:05,940 --> 00:19:17,720 Module here. So, we'll say authenticate require./authenticate. 243 00:19:18,000 --> 00:19:26,740 So, then, when in your code here, 244 00:19:26,740 --> 00:19:29,270 we can now say authenticate.getToken, 245 00:19:31,530 --> 00:19:37,585 and the getToken takes parameter here. 246 00:19:37,585 --> 00:19:41,875 Now, recall, going back authenticate.js file. 247 00:19:41,875 --> 00:19:46,665 The authenticate.js file takes one parameter here 248 00:19:46,665 --> 00:19:53,105 which will be used as the payload when you're creating the JsonWebToken. 249 00:19:53,105 --> 00:19:55,785 So, in the users.js file, 250 00:19:55,785 --> 00:19:59,230 I'm going to create a token by giving a payload, 251 00:19:59,230 --> 00:20:02,890 which only contains the ID of the user. 252 00:20:02,890 --> 00:20:06,070 So, we'll say id: req.user._id. 253 00:20:06,740 --> 00:20:11,940 That is sufficient enough for creating the JsonWebToken. 254 00:20:11,940 --> 00:20:15,315 We don't want to include any other of the user's information. 255 00:20:15,315 --> 00:20:18,690 If you choose to, you can include other parts of the user information, 256 00:20:18,690 --> 00:20:21,715 but I would suggest that keep the JsonWebToken small. 257 00:20:21,715 --> 00:20:25,700 The user ID is sufficient enough because if you need to search for the user, 258 00:20:25,700 --> 00:20:32,840 the user ID is enough to search in the MongoDB for the user. 259 00:20:32,840 --> 00:20:39,230 So, I'm just going to encode only the ID of the user here. 260 00:20:39,230 --> 00:20:44,930 Now, you know that the req.user would be already present, 261 00:20:44,930 --> 00:20:50,530 because when the passport.authenticate('local') successfully authenticates the user, 262 00:20:50,530 --> 00:20:54,650 this is going to load up the user property onto the request message. 263 00:20:54,650 --> 00:20:57,300 So, that's why I'm able to do this here. 264 00:20:57,300 --> 00:21:01,830 So, this is what I will use to create the token. 265 00:21:01,900 --> 00:21:05,120 Now, once the token is created, 266 00:21:05,120 --> 00:21:09,720 I want to pass this token back to the user. 267 00:21:09,720 --> 00:21:15,715 So, in the rest.json object that I am supplying here, 268 00:21:15,715 --> 00:21:21,755 I am already carrying the success true flag and also, 269 00:21:21,755 --> 00:21:23,855 a status message here. 270 00:21:23,855 --> 00:21:28,270 Let me add in the token 271 00:21:28,270 --> 00:21:34,880 as one of the properties in the reply message here. 272 00:21:36,480 --> 00:21:39,475 So, the token that I've just created, 273 00:21:39,475 --> 00:21:47,595 I will pass this back as the second property inside of this Json string here. 274 00:21:47,595 --> 00:21:55,370 So now, when my client receives this Json string in the body of the reply message, 275 00:21:55,370 --> 00:21:59,870 it can go in and extract the token from there. 276 00:22:00,140 --> 00:22:05,500 That's it. So, we have now updated the users.js file, 277 00:22:05,500 --> 00:22:08,630 and you can now see how the token will be 278 00:22:08,630 --> 00:22:12,690 created and sent back to the user when the user is successfully authenticated. 279 00:22:12,690 --> 00:22:16,330 Now, this scheme can also be used 280 00:22:16,330 --> 00:22:21,250 when you use third-party authentication like based on OAuth 2.0, 281 00:22:21,250 --> 00:22:23,525 which we will examine in the next module. 282 00:22:23,525 --> 00:22:25,695 Now, the procedure will be similar. 283 00:22:25,695 --> 00:22:28,880 You will be creating a token when the user is authenticated by 284 00:22:28,880 --> 00:22:32,560 the third-party or OAuth authentication provider, 285 00:22:32,560 --> 00:22:35,640 and then you will pass the token back to the user, 286 00:22:35,640 --> 00:22:39,010 in a similar approach as you see here. 287 00:22:39,010 --> 00:22:41,285 Now, once we have done this, 288 00:22:41,285 --> 00:22:44,255 then we go to app.js file. 289 00:22:44,255 --> 00:22:53,660 In app.js file, because we have included a config file here. 290 00:22:53,660 --> 00:22:59,005 So, let me require the config file here, 291 00:22:59,005 --> 00:23:06,465 and then the URL that I'm using here instead of hardcoding this URL, 292 00:23:06,465 --> 00:23:11,345 I will say config.mongoUrl. 293 00:23:11,345 --> 00:23:16,680 So, now, you see how my config.js file can be used as 294 00:23:16,680 --> 00:23:23,520 a centralized place where I can prepare the configuration for my application. 295 00:23:23,520 --> 00:23:29,200 That's it. So, what happens now is that when the user 296 00:23:29,200 --> 00:23:35,010 authenticates on the /login endpoint and the user is successfully authenticated, 297 00:23:35,010 --> 00:23:40,840 then the token will be created by the server and sent back to the client or the user. 298 00:23:40,840 --> 00:23:43,765 So, the client will include the token in 299 00:23:43,765 --> 00:23:47,765 every subsequent incoming request in the authorization header. 300 00:23:47,765 --> 00:23:50,590 Now, how does it include the authorization header? 301 00:23:50,590 --> 00:23:54,220 Let's go back to authentic.js and here, 302 00:23:54,220 --> 00:24:01,625 you see that we said ExtractJWT.fromAuthHeaderAsBearerToken here. 303 00:24:01,625 --> 00:24:06,290 So, this will be included in the authentication header as a bearer token. 304 00:24:06,290 --> 00:24:08,385 I'll show you how this is done, 305 00:24:08,385 --> 00:24:15,535 then we use postman to include the bearer token into the authentication header. 306 00:24:15,535 --> 00:24:17,690 Now, when this comes in, 307 00:24:17,690 --> 00:24:21,060 then you recall that right down below here, 308 00:24:21,060 --> 00:24:25,095 you have configured this method here called verifyUser, 309 00:24:25,095 --> 00:24:30,635 which calls upon the passport authenticate with JWT. 310 00:24:30,635 --> 00:24:34,460 So, this one uses the token that 311 00:24:34,460 --> 00:24:38,620 comes in the authentication header and then verifies the user. 312 00:24:38,620 --> 00:24:41,980 So, anytime I want to verify the user's authenticity, 313 00:24:41,980 --> 00:24:43,855 I can simply call verify user, 314 00:24:43,855 --> 00:24:49,115 and that will initiate the call to the passport.authenticate and verify the sser. 315 00:24:49,115 --> 00:24:50,315 If this is successful, 316 00:24:50,315 --> 00:24:51,800 it will allow me to proceed. 317 00:24:51,800 --> 00:24:55,620 This procedure is very similar to what you have done in the 318 00:24:55,620 --> 00:25:01,610 users.js file where you call upon the same passport.authenticate('local'). 319 00:25:01,720 --> 00:25:04,320 So, if this is successful, 320 00:25:04,320 --> 00:25:05,885 then you go forward. 321 00:25:05,885 --> 00:25:10,930 If it fails, the authentication function will return the error message 322 00:25:10,930 --> 00:25:16,050 back to the client saying that the user is not authorized. 323 00:25:16,050 --> 00:25:18,345 So, that is already taken care of. 324 00:25:18,345 --> 00:25:23,020 So now, that we have included this into my authenticate.js file, 325 00:25:23,020 --> 00:25:26,050 any place that I want to verify the user, 326 00:25:26,050 --> 00:25:27,480 I can simply call upon 327 00:25:27,480 --> 00:25:31,210 this verifyUser function that 328 00:25:31,210 --> 00:25:34,320 I have specified here or the export that I've specified here, 329 00:25:34,320 --> 00:25:37,220 which we'll call upon the passport.authenticate using 330 00:25:37,220 --> 00:25:40,540 the JWT strategy to authenticate the user. 331 00:25:40,540 --> 00:25:42,440 Now, how do we make use of this? 332 00:25:42,440 --> 00:25:47,785 Now, what we're going to do is we're going to go into each and every one of our routers, 333 00:25:47,785 --> 00:25:56,945 and control the options on all the routes that we want to control. 334 00:25:56,945 --> 00:26:00,300 So, going back to app.js file, now, 335 00:26:00,300 --> 00:26:07,925 that we are not using sessions I'm going to remove this session from here, 336 00:26:07,925 --> 00:26:10,150 because we are no longer using sessions. 337 00:26:10,150 --> 00:26:14,990 Similarly, I'm going to remove this passport.session from here also. 338 00:26:14,990 --> 00:26:17,580 That is also not need. 339 00:26:17,580 --> 00:26:20,430 Also, this authentication, see earlier, 340 00:26:20,430 --> 00:26:21,940 when I configured this authentication, 341 00:26:21,940 --> 00:26:25,490 this authentication was applied to every single incoming request. 342 00:26:25,490 --> 00:26:28,705 Now, I'm going to change my application, 343 00:26:28,705 --> 00:26:35,055 whereby I will require authentication only on certain routes and not on all the routes. 344 00:26:35,055 --> 00:26:39,665 So, let me remove this authentication completely from app.js. 345 00:26:39,665 --> 00:26:41,995 So, now, when the request comes in, 346 00:26:41,995 --> 00:26:45,850 if it is on / endpoint, 347 00:26:45,850 --> 00:26:47,080 the index will be served. 348 00:26:47,080 --> 00:26:52,040 If it is on /users endpoint it'll allow you to navigate to 349 00:26:52,040 --> 00:26:57,815 the various routes that are mounted onto the /users in the users.js, 350 00:26:57,815 --> 00:27:00,900 and then subsequently, the rest of the ones. 351 00:27:00,900 --> 00:27:03,420 What I'm going to do now is I'm going to leave 352 00:27:03,420 --> 00:27:07,250 the public folder open for anybody to access. 353 00:27:07,250 --> 00:27:09,145 Now, in many applications, 354 00:27:09,145 --> 00:27:10,665 this may be just fine. 355 00:27:10,665 --> 00:27:13,045 So, I'm going to leave that open. 356 00:27:13,045 --> 00:27:14,825 Now, on the dishes, 357 00:27:14,825 --> 00:27:17,920 promotions, and the leaders' endpoint, 358 00:27:17,920 --> 00:27:20,875 All the get requests. 359 00:27:20,875 --> 00:27:28,205 I will let those be replied to without requiring any authentication. 360 00:27:28,205 --> 00:27:30,200 Now why would I want to do that? 361 00:27:30,200 --> 00:27:33,190 If a user is doing a get request, 362 00:27:33,190 --> 00:27:35,455 the user just wants to retrieve information. 363 00:27:35,455 --> 00:27:40,490 So, for example, on the client side if I'm implementing a web application using Angular 364 00:27:40,490 --> 00:27:46,290 or a client application using Ionic or native script, 365 00:27:46,290 --> 00:27:49,920 then maybe I want to implement my app in 366 00:27:49,920 --> 00:27:54,310 such a way that the main page will display information already, 367 00:27:54,310 --> 00:27:57,715 the genetic information that you want to make available to anybody that 368 00:27:57,715 --> 00:28:01,590 visits your website or that opens your app. 369 00:28:01,590 --> 00:28:04,360 So, basic information can be displayed there. 370 00:28:04,360 --> 00:28:08,060 But if you want to change anything, 371 00:28:08,060 --> 00:28:12,110 then you expect the user to be authenticated. 372 00:28:12,110 --> 00:28:16,255 So, you will allow POST operations, put operations, 373 00:28:16,255 --> 00:28:21,110 and delete operations to be done only by authenticated users. 374 00:28:21,110 --> 00:28:23,605 Similarly, for comments for example, 375 00:28:23,605 --> 00:28:30,280 you can say that comments can be only posted or modified by authenticated users. 376 00:28:30,280 --> 00:28:34,570 So, you can restrict only some routes for authenticated users, 377 00:28:34,570 --> 00:28:37,940 the other route you can leave them open. How do we do that? 378 00:28:37,940 --> 00:28:41,180 Now this is where the verify user that we 379 00:28:41,180 --> 00:28:45,055 have exported from authenticate.js file comes in handy. 380 00:28:45,055 --> 00:28:49,460 Now instead of controlling all the end points, 381 00:28:49,460 --> 00:28:53,190 all the various operations on the dishes, promotions, 382 00:28:53,190 --> 00:28:54,740 and leaders in points, 383 00:28:54,740 --> 00:28:58,240 we will open only the get operations for anybody, 384 00:28:58,240 --> 00:29:00,830 but the post, put, 385 00:29:00,830 --> 00:29:04,995 and delete operations will be restricted only to authenticated users. 386 00:29:04,995 --> 00:29:10,350 In the assignment, you will add in one more category of users called admin users. 387 00:29:10,350 --> 00:29:15,320 Now you would restrict certain operations to be performed only by admin users. 388 00:29:15,320 --> 00:29:18,460 So, for example, modifying the dishes 389 00:29:18,460 --> 00:29:22,530 or deleting the dishes information from the database, 390 00:29:22,530 --> 00:29:24,600 will be restricted only to admin users. 391 00:29:24,600 --> 00:29:30,000 But basic users can post comments, 392 00:29:30,000 --> 00:29:32,470 modify the comments that they have posted, 393 00:29:32,470 --> 00:29:35,450 and perhaps even save some favorite dishes. 394 00:29:35,450 --> 00:29:38,520 We'll do that part in the fourth module. 395 00:29:38,520 --> 00:29:42,735 Now so how do we control specific routes? 396 00:29:42,735 --> 00:29:46,210 So this is where we have to go into each of the routers 397 00:29:46,210 --> 00:29:50,365 and then import controls on specific routes. 398 00:29:50,365 --> 00:29:53,945 So, let's start with the dishes route. 399 00:29:53,945 --> 00:29:55,770 So, for the dishes route, 400 00:29:55,770 --> 00:29:59,950 you'll recall that this is controlled in dishRouter.js file. 401 00:29:59,950 --> 00:30:02,515 So, going to dishRouter.js, 402 00:30:02,515 --> 00:30:07,450 let's first import the authenticate here. 403 00:30:07,450 --> 00:30:13,400 So we'll say, const authenticate 404 00:30:17,010 --> 00:30:24,700 require../ authenticate because this 405 00:30:24,700 --> 00:30:29,110 authenticator.js file is in the higher level folder. 406 00:30:29,110 --> 00:30:32,105 So, remember../ authenticate here. 407 00:30:32,105 --> 00:30:34,505 So, once you import the authenticate, 408 00:30:34,505 --> 00:30:37,965 for the dish router route for this route, 409 00:30:37,965 --> 00:30:42,560 the get operation, I'm going to allow without any problem. 410 00:30:42,560 --> 00:30:44,820 So, that is open. 411 00:30:44,820 --> 00:30:47,025 So I'm not going to impose any restriction. 412 00:30:47,025 --> 00:30:51,750 From the post, if we want to apply multiple middleware, 413 00:30:51,750 --> 00:30:56,035 we can simply add the main inside this one behind the other. 414 00:30:56,035 --> 00:30:58,050 Now when the post is called, 415 00:30:58,050 --> 00:31:02,295 right now you are simply executing this function here. 416 00:31:02,295 --> 00:31:04,150 Now just before that, 417 00:31:04,150 --> 00:31:12,400 I can go in and say, authenticate.verifyUser, there. 418 00:31:12,400 --> 00:31:13,805 So, what does this do? 419 00:31:13,805 --> 00:31:17,210 This says that if a post request comes in, 420 00:31:17,210 --> 00:31:20,940 I would first execute this middleware, 421 00:31:20,940 --> 00:31:24,805 which I have exported from the authentic.js file, 422 00:31:24,805 --> 00:31:26,100 I first apply that, 423 00:31:26,100 --> 00:31:32,075 which is equivalent to saying passport authenticate JWT and you are checking the user. 424 00:31:32,075 --> 00:31:34,655 Then if this is successful, 425 00:31:34,655 --> 00:31:38,890 then I will move on to do the rest of it. 426 00:31:38,890 --> 00:31:42,955 If the authentication fails at this point, 427 00:31:42,955 --> 00:31:46,290 then passport authenticate will reply 428 00:31:46,290 --> 00:31:49,395 back to the client with the appropriate error message. 429 00:31:49,395 --> 00:31:51,640 So that is already handled by passport authenticate, 430 00:31:51,640 --> 00:31:54,350 so I don't have to worry anything beyond that point. 431 00:31:54,350 --> 00:31:58,300 If I have crossed this middleware and then get to 432 00:31:58,300 --> 00:32:02,990 execute the next function that means that my authentication was successful, 433 00:32:02,990 --> 00:32:05,560 so I'm able to proceed forward from this point. 434 00:32:05,560 --> 00:32:11,760 So, this is acting as the barrier for this post method. 435 00:32:11,760 --> 00:32:14,860 Now using the same argument, 436 00:32:14,860 --> 00:32:21,435 I can simply apply this particular middleware to all the other methods. 437 00:32:21,435 --> 00:32:23,845 I can do that to the put. 438 00:32:23,845 --> 00:32:26,030 Although in this case, 439 00:32:26,030 --> 00:32:28,640 put is not going to be doing anything. 440 00:32:28,640 --> 00:32:30,110 But in any case, 441 00:32:30,110 --> 00:32:33,980 I will simply just for the sake of uniformity, 442 00:32:33,980 --> 00:32:38,490 I will apply the verify user to also put and of course, 443 00:32:38,490 --> 00:32:41,315 for delete too, I'm going to apply put. 444 00:32:41,315 --> 00:32:44,805 Similarly, going down to the /dishId, 445 00:32:44,805 --> 00:32:48,915 get I will allow that to work without any problem. 446 00:32:48,915 --> 00:32:52,470 Post, I will apply the verify user. 447 00:32:52,470 --> 00:32:59,600 Put also I will apply the verify user and for delete also same. 448 00:32:59,600 --> 00:33:09,105 For the /dishId/comments, I'm going to leave the get open, 449 00:33:09,105 --> 00:33:14,030 it's okay for anybody to retrieve comments about a specific dish. 450 00:33:14,030 --> 00:33:17,140 Post, I'm going to close this off, 451 00:33:17,140 --> 00:33:21,995 so only verified users can post comments. 452 00:33:21,995 --> 00:33:27,710 Put also I will close this off and delete too. 453 00:33:29,280 --> 00:33:33,035 You need to go one step further and say, 454 00:33:33,035 --> 00:33:38,230 "Only the users that have posted the comment can delete their own posts." 455 00:33:38,230 --> 00:33:40,310 But we will do that in the next module. 456 00:33:40,310 --> 00:33:41,840 For the moment, I'm going to say, 457 00:33:41,840 --> 00:33:44,415 "Okay, a verified user can delete any comment." 458 00:33:44,415 --> 00:33:46,715 This is of course not true, 459 00:33:46,715 --> 00:33:48,850 we can put an additional checks, 460 00:33:48,850 --> 00:33:52,145 but we will do that in the next module of this course. 461 00:33:52,145 --> 00:33:54,405 So, for delete also I apply the same. 462 00:33:54,405 --> 00:33:58,060 Again, for the dish router comments/ comments Id, 463 00:33:58,060 --> 00:34:00,300 get I'll leave it as open. 464 00:34:00,300 --> 00:34:04,485 Post, I will leave it closed. 465 00:34:04,485 --> 00:34:12,640 Put also close it off and then for delete also I will close this off. 466 00:34:12,640 --> 00:34:14,970 Delete of course as I said, 467 00:34:14,970 --> 00:34:19,180 the delete operation should be allowed only a user that 468 00:34:19,180 --> 00:34:24,150 has created the comment should be asked to delete that, 469 00:34:24,150 --> 00:34:27,960 but you need to set up a few additional things for that to work correctly, 470 00:34:27,960 --> 00:34:30,825 which we will do in the next module. 471 00:34:30,825 --> 00:34:36,455 For the moment, we're saying a verified user can delete a specific comment, that's it. 472 00:34:36,455 --> 00:34:42,820 Now we will apply the same principle to the promo router and also the leader router. 473 00:34:42,820 --> 00:34:44,950 So, going into the promo router, 474 00:34:44,950 --> 00:34:53,100 let me import authenticate 475 00:34:57,320 --> 00:35:00,870 and then get is open, 476 00:35:00,870 --> 00:35:03,540 so this is leader router. 477 00:35:03,540 --> 00:35:05,380 So, get is open. 478 00:35:05,380 --> 00:35:08,365 Post, I'm going to control that, 479 00:35:08,365 --> 00:35:12,865 put, control, delete, control, 480 00:35:12,865 --> 00:35:14,790 leader router, leader ID, 481 00:35:14,790 --> 00:35:17,255 get is okay, post, 482 00:35:17,255 --> 00:35:22,330 controlled, put is controlled and delete is controlled. 483 00:35:22,330 --> 00:35:24,795 Same thing with promo router. 484 00:35:24,795 --> 00:35:38,652 Let me, require the authenticate 485 00:35:38,652 --> 00:35:43,570 and then for the route get is open, 486 00:35:43,570 --> 00:35:47,109 POST is controlled, put is controlled, 487 00:35:47,109 --> 00:35:50,790 delete is controlled, same thing for the promoRouter/promoID. 488 00:35:50,790 --> 00:35:54,460 Get is open, POST is controlled, 489 00:35:54,460 --> 00:35:58,395 put and delete are also controlled, that's it. 490 00:35:58,395 --> 00:36:00,225 Let's save all the changes. 491 00:36:00,225 --> 00:36:02,660 So, once we complete all the changes, 492 00:36:02,660 --> 00:36:04,185 let's save the changes. 493 00:36:04,185 --> 00:36:08,270 Now, our application is ready to be tested. 494 00:36:08,270 --> 00:36:11,485 So, let's go and restart our server, 495 00:36:11,485 --> 00:36:14,885 or if the server is not running, 496 00:36:14,885 --> 00:36:16,590 we'll just start the server. 497 00:36:16,590 --> 00:36:18,770 Going to the terminal, 498 00:36:18,770 --> 00:36:20,040 my server is not running. 499 00:36:20,040 --> 00:36:23,930 So, let me start the server by typing npm start. 500 00:36:24,620 --> 00:36:28,935 Interestingly, it just thrown an error here, 501 00:36:28,935 --> 00:36:32,330 I just wanted to illustrate to you that even I can make mistakes, 502 00:36:32,330 --> 00:36:34,840 so you'll see that there is an error here which says, 503 00:36:34,840 --> 00:36:40,275 "Cannot find module.authenticate," and then if I look through the code, 504 00:36:40,275 --> 00:36:45,255 I find that this problem occurred in the, 505 00:36:45,255 --> 00:36:46,850 where did it occur? 506 00:36:46,850 --> 00:36:48,350 So, I just search here, 507 00:36:48,350 --> 00:36:50,020 and then somewhere down here, 508 00:36:50,020 --> 00:36:56,130 I noticed that this problem occurred inside my users.js file. 509 00:36:56,130 --> 00:36:57,870 So, right there, it says, 510 00:36:57,870 --> 00:37:00,355 this is in the users.js file. 511 00:37:00,355 --> 00:37:05,655 So, going to the users.js file, let's fix that. 512 00:37:05,655 --> 00:37:09,015 Going to users.js file, 513 00:37:09,015 --> 00:37:14,285 right at the top when I required authenticate, I said, 514 00:37:14,285 --> 00:37:17,555 ''.authenticate,'' and as I was telling you, 515 00:37:17,555 --> 00:37:21,200 that should be a dot dot because it's in the upper folder. 516 00:37:21,200 --> 00:37:25,905 This users.js file in the Routes folder, 517 00:37:25,905 --> 00:37:31,985 and authenticate is in the Projects Route folder so this should be dot dot authenticate. 518 00:37:31,985 --> 00:37:34,660 So, if you make mistakes, there you go, 519 00:37:34,660 --> 00:37:40,450 that's how you're going to be reminded of the error that you've introduced. 520 00:37:40,450 --> 00:37:44,540 So, let's save the changes and then restart our server. 521 00:37:44,540 --> 00:37:47,795 Again, going back to that terminal, 522 00:37:47,795 --> 00:37:54,735 let me start my server and my server is now up and running, 523 00:37:54,735 --> 00:38:00,235 let's go to Postman and then test our application. 524 00:38:00,235 --> 00:38:04,695 Now, in Postman, let me first try to do 525 00:38:04,695 --> 00:38:11,170 a GET on localhost:3000/dishes and then when I do a GET, 526 00:38:11,170 --> 00:38:15,620 it is successful because the GET end point is not controlled. 527 00:38:15,620 --> 00:38:18,595 So I can do a GET on dishes, 528 00:38:18,595 --> 00:38:23,545 I can do a GET on promotions, 529 00:38:23,545 --> 00:38:25,420 and it all works just fine. 530 00:38:25,420 --> 00:38:28,300 But if I try to do a POST on dishes, 531 00:38:28,300 --> 00:38:32,435 so let me find where I have done a POST on dishes. 532 00:38:32,435 --> 00:38:35,245 Here I have done a POST on dishes. 533 00:38:35,245 --> 00:38:38,030 So, when I tried to do a POST on dishes, 534 00:38:38,030 --> 00:38:40,540 it immediately says unauthorized. 535 00:38:40,540 --> 00:38:47,410 So my Passport module has realized that I'm not authorized so I'm not allowed to do this, 536 00:38:47,410 --> 00:38:49,825 so that's what it is reminding me about. 537 00:38:49,825 --> 00:38:52,750 Let me clean out the cookies from, 538 00:38:52,750 --> 00:38:57,980 in case you find a cookie in your Postman just remove the cookie 539 00:38:57,980 --> 00:39:00,410 corresponding to the localhost because 540 00:39:00,410 --> 00:39:03,815 that cookie is no longer needed and will not be required. 541 00:39:03,815 --> 00:39:06,100 So, even if I remove the cookie and then POST, 542 00:39:06,100 --> 00:39:07,990 it will still say unauthorized. 543 00:39:07,990 --> 00:39:11,715 So, I'm not authorized for doing these operations. 544 00:39:11,715 --> 00:39:13,305 So, I have to login. 545 00:39:13,305 --> 00:39:15,430 Now, if you have done the previous exercise, 546 00:39:15,430 --> 00:39:19,390 you would have left the user that you signed up earlier. 547 00:39:19,390 --> 00:39:25,865 So, for example, you'd have signed up this particular user in the previous exercise, 548 00:39:25,865 --> 00:39:29,530 let me try to sign up the same user again and 549 00:39:29,530 --> 00:39:36,090 my server should complain saying UserExistsError so that means that the user exists, 550 00:39:36,090 --> 00:39:38,455 so I don't need to sign up again. 551 00:39:38,455 --> 00:39:42,290 If you have deleted the user from your MongoDB, 552 00:39:42,290 --> 00:39:47,275 just sign up that user one more time and then let's login. 553 00:39:47,275 --> 00:39:55,830 So, we will send a login request to that end point. 554 00:39:55,830 --> 00:40:00,640 So, when I send the login request by doing a POST to the end-user, 555 00:40:00,640 --> 00:40:03,365 notice what is returned by my server. 556 00:40:03,365 --> 00:40:06,965 You immediately notice that in the reply message 557 00:40:06,965 --> 00:40:10,830 along with the success flag and the status message, 558 00:40:10,830 --> 00:40:13,740 you also get a token here. 559 00:40:13,740 --> 00:40:16,365 Now, this particular token, 560 00:40:16,365 --> 00:40:17,960 I need to copy this token, 561 00:40:17,960 --> 00:40:21,045 because in my subsequent requests, 562 00:40:21,045 --> 00:40:23,535 I will need to include this token. 563 00:40:23,535 --> 00:40:31,610 So, let me go to the raw version of this and that I'm going to copy this token. 564 00:40:31,610 --> 00:40:33,875 This token is nothing but a long string there, 565 00:40:33,875 --> 00:40:36,260 so let me copy this token. 566 00:40:36,260 --> 00:40:41,765 Then now if you are curious about what is contained in this token, 567 00:40:41,765 --> 00:40:44,800 the JSON Web Token can be examined. 568 00:40:44,800 --> 00:40:48,140 There is a particular site where you can go in and type 569 00:40:48,140 --> 00:40:52,235 in your JSON Web Token and then actually check what is inside the JSON Web Token. 570 00:40:52,235 --> 00:40:54,980 Let's do that as the next step. 571 00:40:54,980 --> 00:40:56,685 In a browser window, 572 00:40:56,685 --> 00:41:05,565 just type jwt.io and this will take you to this site called JSON Web Token jwt.io. 573 00:41:05,565 --> 00:41:07,590 If you recall, in the lecture, 574 00:41:07,590 --> 00:41:10,685 I had shown you the structure of the JSON Web Token 575 00:41:10,685 --> 00:41:14,290 and had shown you that the JSON Web Token contains three parts: the header, 576 00:41:14,290 --> 00:41:18,040 the payload, and the information there. 577 00:41:18,040 --> 00:41:19,730 Now, in this case, 578 00:41:19,730 --> 00:41:25,880 the information is up here so I am going 579 00:41:25,880 --> 00:41:33,285 to paste my JSON Web Token into this left-hand side, 580 00:41:33,285 --> 00:41:37,270 so let me select that and then paste my JSON Web Token into 581 00:41:37,270 --> 00:41:41,920 the left-hand side in the encoded part and then on the right-hand side, 582 00:41:41,920 --> 00:41:46,030 it is showing you exactly what is inside the JSON Web Token that I just created. 583 00:41:46,030 --> 00:41:49,580 So, it says the header contains these two pieces of information. 584 00:41:49,580 --> 00:41:54,090 The payload notice that it contains the ID of 585 00:41:54,090 --> 00:41:59,245 the user and then the signature at the bottom here. 586 00:41:59,245 --> 00:42:03,995 So, this is what is contained inside my JSON Web Token. 587 00:42:03,995 --> 00:42:07,005 Going back to Postman, 588 00:42:07,005 --> 00:42:12,110 let me now try to GET the dishes. 589 00:42:12,110 --> 00:42:15,940 So, when I say GET localhost:3000/dishes, 590 00:42:15,940 --> 00:42:18,650 it will still return an empty string, 591 00:42:18,650 --> 00:42:23,385 empty array here because my database doesn't contain it. 592 00:42:23,385 --> 00:42:29,635 So, let me POST a dish to my database. 593 00:42:29,635 --> 00:42:33,290 So, I'm going to choose the POST operation and in the body, 594 00:42:33,290 --> 00:42:36,095 you see that I have my dish here. 595 00:42:36,095 --> 00:42:41,215 In the header, I'm going to add in the new header called 596 00:42:41,215 --> 00:42:47,240 authorization and you recall that earlier for basic authorization, 597 00:42:47,240 --> 00:42:53,425 you said basic and then you had the Base 64 encoded string there. 598 00:42:53,425 --> 00:42:58,970 If you want to include your JSON Web Token in the authorization header, 599 00:42:58,970 --> 00:43:01,150 because in our code, 600 00:43:01,150 --> 00:43:04,550 we said authorization as bearer token. 601 00:43:04,550 --> 00:43:08,040 So, if you want to include the token in the authorization header, 602 00:43:08,040 --> 00:43:13,275 in the authorization we'll say bearer and then we will paste 603 00:43:13,275 --> 00:43:19,080 that token string that we have just copied from our incoming request. 604 00:43:19,080 --> 00:43:21,935 So, we'll paste the token string in there. 605 00:43:21,935 --> 00:43:24,360 So, this is what will be contained in 606 00:43:24,360 --> 00:43:29,795 the authorization header of my outgoing request here, 607 00:43:29,795 --> 00:43:33,845 outgoing POST request here. 608 00:43:33,845 --> 00:43:39,970 So notice, the left side says bearer and the right side is the string, 609 00:43:39,970 --> 00:43:43,230 the token that I have just copied from 610 00:43:43,230 --> 00:43:48,460 the point where I logged in and then let me send the POST message 611 00:43:48,460 --> 00:43:57,590 now and my POST is now successful and this is posted to my database. 612 00:43:57,590 --> 00:44:01,115 Now, if you want to be sure that it has been posted, 613 00:44:01,115 --> 00:44:04,555 let's do a GET and when you do a GET, 614 00:44:04,555 --> 00:44:12,935 you can see that indeed that dish has been inserted into my database as shown here. 615 00:44:12,935 --> 00:44:19,260 So, this is how you will be making use of JSON Web Tokens in your application. 616 00:44:19,260 --> 00:44:22,230 So, whenever you need to do a POST, PUT, 617 00:44:22,230 --> 00:44:25,505 or a DELETE operation on any of the endpoints, 618 00:44:25,505 --> 00:44:27,010 you would be enclosing. 619 00:44:27,010 --> 00:44:33,895 So, let me go back to this POST request here. 620 00:44:33,895 --> 00:44:35,890 In the header, you will put 621 00:44:35,890 --> 00:44:41,540 this authorization field and then this would be included in the authorization, 622 00:44:41,540 --> 00:44:47,540 you will start it with bearer and then the token string, 623 00:44:47,540 --> 00:44:50,200 after that bearer space, 624 00:44:50,200 --> 00:44:54,215 one single space and then the token string following that. 625 00:44:54,215 --> 00:44:58,310 So, that is how your request messages would 626 00:44:58,310 --> 00:45:03,140 carry the JSON Web Token in the header of the outgoing request message. 627 00:45:03,140 --> 00:45:08,220 You can also include the token in the body of the outgoing request message. 628 00:45:08,220 --> 00:45:10,310 Now, for that, you will have to configure 629 00:45:10,310 --> 00:45:18,210 your express server especially the extra JWT in the 630 00:45:18,210 --> 00:45:21,120 authenticate.js file to accept it from 631 00:45:21,120 --> 00:45:24,455 the body so you recall that there we have seen that 632 00:45:24,455 --> 00:45:28,890 the extra JWT supports many different ways of extracting 633 00:45:28,890 --> 00:45:33,695 the JSON Web Token from the incoming request. 634 00:45:33,695 --> 00:45:35,090 So, there you need to specify, 635 00:45:35,090 --> 00:45:36,670 if you're going to be including it in the body, 636 00:45:36,670 --> 00:45:39,115 you need to specify that information there. 637 00:45:39,115 --> 00:45:42,395 Now, the details of how to do that you can consult 638 00:45:42,395 --> 00:45:49,885 the Passport JWT module documentation to understand how this is done. 639 00:45:49,885 --> 00:45:54,610 In this course, I'm going to simply use that in the authorization header 640 00:45:54,610 --> 00:45:59,835 as I have shown here and this works just fine for most cases. 641 00:45:59,835 --> 00:46:02,620 Now, if you are developing a Web app, 642 00:46:02,620 --> 00:46:06,635 an Angular app, or an Ionic or NativeScript app, 643 00:46:06,635 --> 00:46:09,800 you need to be able to configure 644 00:46:09,800 --> 00:46:16,615 that app whereby the JSON Web Token will be included in the authorization header. 645 00:46:16,615 --> 00:46:22,215 In the last lesson of this course, 646 00:46:22,215 --> 00:46:26,255 I will show you how to integrate the client and the server, 647 00:46:26,255 --> 00:46:29,310 the client that you have developed in the previous courses with 648 00:46:29,310 --> 00:46:32,495 the server that we developed in this course. 649 00:46:32,495 --> 00:46:35,120 With this, we complete this exercise. 650 00:46:35,120 --> 00:46:37,940 In this exercise, we have seen how we 651 00:46:37,940 --> 00:46:42,200 can configure our application to use JSON Web Tokens, 652 00:46:42,200 --> 00:46:50,555 and we have seen how we handle the authentication of the user using the JSON Web Token, 653 00:46:50,555 --> 00:46:55,555 using the support from the Passport module and the Passport JWT module, 654 00:46:55,555 --> 00:46:58,605 and the JSON Web Token Node modules. 655 00:46:58,605 --> 00:47:01,090 With this, we complete this exercise. 656 00:47:01,090 --> 00:47:09,110 This is a good time for you to do a Git Commit with the message Passport JWT.