1
00:00:00,180 --> 00:00:05,640
In this video you'll be setting up an express middleware function you can use to add authentication

2
00:00:05,640 --> 00:00:08,110
to any request in your application.

3
00:00:08,130 --> 00:00:11,830
We're going to use the same principles we discussed in the last video.

4
00:00:11,910 --> 00:00:18,390
Although the function in this case will check for an incoming authentication token it will verify that

5
00:00:18,390 --> 00:00:21,060
it is a valid Jason web token.

6
00:00:21,060 --> 00:00:24,120
Then it will find the associated user.

7
00:00:24,150 --> 00:00:30,060
Now when we first explore and express middleware in the last one we just defined our middleware functions

8
00:00:30,060 --> 00:00:34,060
right in line inside of index not J S.

9
00:00:34,080 --> 00:00:36,300
This works well for experimentation.

10
00:00:36,570 --> 00:00:42,630
But when creating middleware to be used throughout your app it's best to define it in a separate file

11
00:00:42,810 --> 00:00:45,240
so we can keep things nice and organized.

12
00:00:45,510 --> 00:00:50,650
Now inside of the source directory we have D.B. models and routers.

13
00:00:50,760 --> 00:00:56,820
We're going to create a brand new directory and they're called middleware now.

14
00:00:56,830 --> 00:01:02,740
Middleware is going to store a new file for each piece of middleware we're trying to define it and in

15
00:01:02,740 --> 00:01:06,790
our case we're gonna have a single middleware function for the moment.

16
00:01:06,880 --> 00:01:14,380
The one concerned with authentication right here I can call that something like off dot J S or authentication.

17
00:01:14,380 --> 00:01:20,780
Dot J S in here we're going to set up and define the authentication middleware.

18
00:01:20,860 --> 00:01:26,540
Then we'll actually load it into our routers to put some of the roots behind authentication.

19
00:01:27,070 --> 00:01:31,900
Let's go ahead and get started though by defining the function we'll be working with right here.

20
00:01:32,020 --> 00:01:38,530
We can create a new constant called auth and we are going to set this up as an async function so I can

21
00:01:38,530 --> 00:01:45,640
take advantage of async and wait right here as we saw in the previous video request response.

22
00:01:45,700 --> 00:01:55,060
And next and all we'll do for the moment is just print a little message right here console dot log off

23
00:01:55,150 --> 00:01:58,860
middleware just to make sure it's running and then down below.

24
00:01:58,870 --> 00:02:03,730
I'll call next to allow the associated root handler to run.

25
00:02:03,730 --> 00:02:09,370
Now remember we're defining the function in this file but I want to export it so it can be used elsewhere.

26
00:02:09,430 --> 00:02:17,680
Right here we'll do just that by setting a module dot exports equal to the off function we justify.

27
00:02:17,980 --> 00:02:23,920
Now we can load this in from other files to use the middleware wherever we need to.

28
00:02:23,950 --> 00:02:30,280
Now in the last video we registered all of our middleware in index dot J S when we do this it's going

29
00:02:30,290 --> 00:02:36,550
to be associated and used for every single route in our application with the off middleware.

30
00:02:36,550 --> 00:02:43,090
That's not what we want certain requests like signing up and logging in should not use the off middleware

31
00:02:43,090 --> 00:02:44,090
at all.

32
00:02:44,110 --> 00:02:46,170
So let's see how we can get this done.

33
00:02:46,210 --> 00:02:49,240
What I'm gonna do is comment out the maintenance middleware.

34
00:02:49,240 --> 00:02:56,160
So our application actually works as expected and we're gonna head over to the user router we're gonna

35
00:02:56,200 --> 00:03:00,610
learn how to set up middleware for an individual route to get started.

36
00:03:00,610 --> 00:03:04,780
We are going to need to require the function we created in that separate file.

37
00:03:04,780 --> 00:03:11,980
So right here const off equals I'll be using require starting with a dot dot to get out of the routers

38
00:03:11,980 --> 00:03:19,630
directory then forward slash middleware forward slash off which is the file we defined now that we have

39
00:03:19,630 --> 00:03:24,040
that in place we can add the off middleware to an individual route.

40
00:03:24,040 --> 00:03:30,130
Now the first one is for signing up and the second is for log in the two routes that we don't want to

41
00:03:30,130 --> 00:03:31,910
add authentication to.

42
00:03:32,080 --> 00:03:34,560
But let's go ahead and add it for the third one.

43
00:03:34,600 --> 00:03:40,060
Get forward slash users to add middleware to an individual route.

44
00:03:40,090 --> 00:03:47,110
All we do is pass it in as an argument to the get method before we pass in our route handler.

45
00:03:47,110 --> 00:03:52,510
So right here the root handler is the second argument to get we're gonna go ahead and move it to the

46
00:03:52,540 --> 00:03:54,450
third argument position.

47
00:03:54,550 --> 00:04:00,310
And the second argument is going to be the middleware function to run which in our case is off.

48
00:04:00,670 --> 00:04:07,030
So now when someone makes a get request to forward slash users it's first going to run our middleware

49
00:04:07,270 --> 00:04:10,000
then it'll go ahead and run the root handler.

50
00:04:10,000 --> 00:04:17,440
Now remember it's only ever going to run the root handler if the middleware calls that next function.

51
00:04:17,470 --> 00:04:22,930
So this is how we're going to get access to control how things are working let's go ahead and see this

52
00:04:22,930 --> 00:04:26,410
in action before expanding on the middleware any further.

53
00:04:26,410 --> 00:04:31,650
So right here I'm gonna make a request to get forward slash users from post man.

54
00:04:31,990 --> 00:04:35,210
I'll go ahead and do just that right here.

55
00:04:35,470 --> 00:04:36,600
I'll send it off.

56
00:04:36,700 --> 00:04:37,480
And what do I get.

57
00:04:37,480 --> 00:04:44,840
I get my users back and over inside of Visual Studio code I have the off middleware message printing.

58
00:04:44,890 --> 00:04:51,130
If I was to fire off a different request like log in it would still indeed work and I wouldn't see that

59
00:04:51,130 --> 00:04:58,100
message down below a second time because the log in route does not use that middleware.

60
00:04:58,120 --> 00:05:04,600
So here by adding about six characters of code we were able to add the middleware to a given route and

61
00:05:04,600 --> 00:05:09,220
we'll be able to do that for all of the routes that should require authentication.

62
00:05:09,220 --> 00:05:16,460
Now let's actually talk about what the off function is going to do to make sure the given user is authenticated.

63
00:05:16,480 --> 00:05:22,480
Now the whole authentication process starts with the client taking that authentication token that they

64
00:05:22,480 --> 00:05:26,620
get from signing up or logging in and providing it with the request.

65
00:05:26,620 --> 00:05:28,290
They're trying to perform.

66
00:05:28,390 --> 00:05:34,420
So in this case I have logged into the user several times and I have my authentication tokens showing

67
00:05:34,420 --> 00:05:34,980
up.

68
00:05:35,110 --> 00:05:41,680
Let's go ahead and grab the authentication token that was just created and sent back with the last login

69
00:05:41,740 --> 00:05:43,570
request right here.

70
00:05:43,570 --> 00:05:49,240
I'm going to copy the entire Jason web token everything inside of those quotes.

71
00:05:49,240 --> 00:05:53,100
And once we had that in the clipboard we'll take it over to the request.

72
00:05:53,110 --> 00:05:59,210
We just added the off middleware to that is get forward slash users.

73
00:05:59,210 --> 00:06:02,320
Now to actually provide the authentication token.

74
00:06:02,360 --> 00:06:09,640
Well we're going to do is set up a request header so we can go over to the headers tab in post man.

75
00:06:09,770 --> 00:06:16,930
And this is where we'll be able to set up key value pairs providing additional information to the server.

76
00:06:16,940 --> 00:06:20,920
Now when we work with headers we can provide them as part of the request.

77
00:06:20,930 --> 00:06:26,390
So sending them from the client to the server and we can also have headers sent back as part of the

78
00:06:26,390 --> 00:06:27,410
response.

79
00:06:27,470 --> 00:06:33,070
So the server can send back some headers to the original requester in this case.

80
00:06:33,110 --> 00:06:36,810
We want to set up headers that get sent as part of the request.

81
00:06:36,860 --> 00:06:42,980
We're providing the authentication token to the server and to do this we'll set up the following header.

82
00:06:42,980 --> 00:06:50,320
It is authorization the authorization header is going to have the following value.

83
00:06:50,450 --> 00:06:59,570
It's going to start off with bearer so B E A R E R that is a capital B followed by a space followed

84
00:06:59,570 --> 00:07:00,700
by the token.

85
00:07:01,160 --> 00:07:07,300
So this is no one as a bearer token in which the client provides the token with the request.

86
00:07:07,310 --> 00:07:13,880
They're trying to perform and this is all the client is going to need to do to actually provide the

87
00:07:14,030 --> 00:07:16,430
information necessary to get authenticated.

88
00:07:16,880 --> 00:07:23,890
So now we can go ahead and figure out how to access this information and then validate it from our server.

89
00:07:23,910 --> 00:07:31,820
So over here and off dot J s Let's go ahead and kick things off by emptying the function we had created

90
00:07:32,090 --> 00:07:38,930
and we're going to load two things in we're going to load any Jason web token library so we can validate

91
00:07:38,960 --> 00:07:44,960
the token being provided and we're also going to load in the User model so we can find them in the database

92
00:07:45,140 --> 00:07:47,810
once we've validated the off token.

93
00:07:47,810 --> 00:07:57,860
So right here a concept JWT and I am going to require the Jason Webb token library then down below on

94
00:07:57,860 --> 00:08:00,560
the next line I'll load in the User model.

95
00:08:00,590 --> 00:08:08,210
So const user equals require we're gonna use dot dot to get out of this middleware directory forward

96
00:08:08,210 --> 00:08:11,610
slash models of forward slash user.

97
00:08:11,660 --> 00:08:17,090
Now that we have both of those in place we can start to fill out the function itself and it's all going

98
00:08:17,090 --> 00:08:24,980
to start with a try catch block so we're going to attempt to run some code that validates the user if

99
00:08:24,980 --> 00:08:31,310
the user isn't valid we will have the catch block down below run if they're not authenticated we're

100
00:08:31,310 --> 00:08:37,190
not going to call next we won't let the route handle or run instead we'll just send an error back.

101
00:08:37,190 --> 00:08:44,270
I'll use response dot status to send back a 4 or 1 status code which lets them know they're not authenticated

102
00:08:44,270 --> 00:08:51,170
correctly and I'll also use send to send back some Jason will have an error property with the following

103
00:08:51,170 --> 00:08:54,200
message Please authenticate.

104
00:08:54,200 --> 00:08:55,180
Perfect.

105
00:08:55,280 --> 00:08:57,360
So this is the error handler.

106
00:08:57,380 --> 00:09:03,350
Now the actual process of validating the token is going to require us to do a bit of work the first

107
00:09:03,350 --> 00:09:10,070
thing we want to do is figure out how to get the value for that header request gives us a way to get

108
00:09:10,070 --> 00:09:10,880
this done.

109
00:09:10,910 --> 00:09:20,420
So right here const token will store the actual value and then we use request dot header to access incoming

110
00:09:20,420 --> 00:09:20,990
headers.

111
00:09:21,020 --> 00:09:23,620
We pass to it the name of the header.

112
00:09:23,630 --> 00:09:30,470
We're trying to get access to now in our case that's going to be authorization exactly like we had before

113
00:09:30,860 --> 00:09:35,780
a u t h perfect authorization.

114
00:09:35,890 --> 00:09:40,290
And now we'd be able to do something with it like validate it for the moment.

115
00:09:40,300 --> 00:09:44,890
Let's just go ahead and log it out to make sure we're actually getting the token correctly.

116
00:09:44,890 --> 00:09:45,760
Right here.

117
00:09:45,760 --> 00:09:52,390
I'm gonna save off dot j ust so the server restarts and I'll make that get user's request an additional

118
00:09:52,390 --> 00:09:52,860
time.

119
00:09:52,870 --> 00:09:57,820
This is the request where we're passing that token along over inside of the server.

120
00:09:57,820 --> 00:09:59,470
What do I get in the terminal.

121
00:09:59,500 --> 00:10:02,060
Right here I have the header value.

122
00:10:02,200 --> 00:10:08,170
It starts off with bearer and then down below we have the actual token showing up.

123
00:10:08,740 --> 00:10:14,920
So the next thing we want to do is get the JWT out of that value and we want to go ahead and verify

124
00:10:14,920 --> 00:10:19,270
that it's correct using these same secret we used when we generated it.

125
00:10:19,480 --> 00:10:25,720
Now in order to get the JWT out of the entire header value all we need to do is remove that barrier

126
00:10:25,750 --> 00:10:29,200
portion which allows us to know it's a bearer token.

127
00:10:29,200 --> 00:10:33,220
Right here we can do that by using the string method replace.

128
00:10:33,250 --> 00:10:39,810
So header returns the string token value and we'll gonna use replace to remove the beginning portion.

129
00:10:39,970 --> 00:10:45,340
We provide two strings what we want to replace and what we want to replace it with.

130
00:10:45,490 --> 00:10:50,380
In this case I am going to replace bearer space with nothing.

131
00:10:50,380 --> 00:10:52,330
Essentially removing it.

132
00:10:52,330 --> 00:10:57,310
Now if there is no authorization header header is going to return undefined.

133
00:10:57,430 --> 00:11:02,230
And if we try to access replace of undefined that's going to throw an error.

134
00:11:02,230 --> 00:11:08,260
Now we could use tri catch to catch that but we already are using tri catch which means that if there

135
00:11:08,260 --> 00:11:13,120
is no token provided the code down below will indeed trigger.

136
00:11:13,120 --> 00:11:16,870
Next up we want to make sure that token is actually valid.

137
00:11:16,870 --> 00:11:21,790
So we want to ensure that it was created by our server and that it has an expired.

138
00:11:22,090 --> 00:11:30,700
So right here const decoded this is going to be the decoded payload for the token and we're going to

139
00:11:30,700 --> 00:11:38,500
use JWT dot verify like we've done before we are verifying the token and we're using the exact same

140
00:11:38,500 --> 00:11:41,580
secret we used to generate it.

141
00:11:41,590 --> 00:11:46,330
Now remember the code for generating the token was defined in the user model.

142
00:11:46,420 --> 00:11:52,900
Right here I have the string that I used to make sure to copy the string that you used as they need

143
00:11:52,900 --> 00:11:54,850
to match up exactly.

144
00:11:54,910 --> 00:11:58,630
I'm gonna take it over to the off middleware and paste it in.

145
00:11:58,690 --> 00:12:04,960
Now we'll know if the given token is indeed valid and from there if it is valid we can focus on finding

146
00:12:04,990 --> 00:12:06,850
the user in the database.

147
00:12:06,850 --> 00:12:10,350
Now we embedded the user's I.D. as part of the token.

148
00:12:10,360 --> 00:12:16,780
So that's what we're going to use to actually grab the user from the database remember we have underscore

149
00:12:16,780 --> 00:12:19,630
I.D. as the thing we've added to that payload.

150
00:12:19,630 --> 00:12:24,090
So decoded has the underscore I.D. property right here.

151
00:12:24,100 --> 00:12:31,330
I'm going to create a new constant user and I'm going to go ahead and use await with user dot right

152
00:12:31,330 --> 00:12:38,530
here find and we're gonna use find one as opposed to find a bi I.D. and we'll talk about why in just

153
00:12:38,530 --> 00:12:45,310
a second right here we're going to provide our search criteria and we're going to start by looking for

154
00:12:45,310 --> 00:12:54,520
a user with the following I.D. the I.D. stored on decoded dot underscore I d perfect.

155
00:12:54,520 --> 00:13:00,490
Now the other thing we want to check is that this token is still part of that tokens array when a user

156
00:13:00,490 --> 00:13:03,190
lives out we're going to delete that token.

157
00:13:03,190 --> 00:13:07,620
So we want to make sure it actually exists inside of there to do this.

158
00:13:07,630 --> 00:13:14,290
We're gonna set up another property on this object but with a string property name and we're gonna use

159
00:13:14,290 --> 00:13:21,670
a string property name because we'll be using a special character inside of their value for this property

160
00:13:21,670 --> 00:13:24,750
is going to be tokens dot token.

161
00:13:24,850 --> 00:13:31,630
This is going to look for a user that has a given token value in one of their array items in the tokens

162
00:13:31,690 --> 00:13:32,490
array.

163
00:13:32,500 --> 00:13:34,510
Now what value are we looking for.

164
00:13:34,780 --> 00:13:39,470
We're looking for the value provided we have the token variable up above.

165
00:13:40,030 --> 00:13:45,820
So all this is going to do is find a user with the correct I.D. who has that authentication token still

166
00:13:45,820 --> 00:13:46,370
stored.

167
00:13:46,390 --> 00:13:50,830
If the user logs out that means this token will be valid.

168
00:13:50,830 --> 00:13:54,040
Now we can go ahead and see if we actually found a user.

169
00:13:54,040 --> 00:14:00,040
So right here if there is no user that is definitely a problem and we want to go ahead and make sure

170
00:14:00,040 --> 00:14:02,440
the code down below runs.

171
00:14:02,440 --> 00:14:10,770
So for that I can just throw a new error to trigger that code and I don't even need to provide an error

172
00:14:10,800 --> 00:14:11,400
message.

173
00:14:11,400 --> 00:14:15,270
This alone is enough to trigger catch down below.

174
00:14:15,270 --> 00:14:22,170
Now if this code runs right here that means things went well and we're going to do two things one we're

175
00:14:22,170 --> 00:14:28,560
going to make sure that the root handler runs since the user has proven they're authenticated correctly.

176
00:14:28,620 --> 00:14:31,500
So for us that means calling next.

177
00:14:31,500 --> 00:14:37,080
The other thing we're going to do is give that root handler access to the user that we fetched from

178
00:14:37,080 --> 00:14:42,840
the database we already fetched them and there's no need for the root handlers to have to fetch the

179
00:14:42,840 --> 00:14:46,820
user again as that would just waste resources and time.

180
00:14:47,280 --> 00:14:50,990
We can actually add a property onto request to store this.

181
00:14:51,090 --> 00:14:54,640
And the root handlers will be able to access it later on.

182
00:14:54,780 --> 00:14:59,430
So request dot we can pick a name like user for this.

183
00:14:59,430 --> 00:15:01,250
And what am I going to store there.

184
00:15:01,260 --> 00:15:05,040
I will store the user variable from up above.

185
00:15:05,040 --> 00:15:07,920
Now that we have this in place let's go ahead and test it out.

186
00:15:07,950 --> 00:15:13,220
And don't worry I'll be recapping what we did here in just a few moments.

187
00:15:13,260 --> 00:15:14,520
So what are we going to do.

188
00:15:14,520 --> 00:15:18,240
We're going to run our request over here from post man.

189
00:15:18,270 --> 00:15:23,940
I'm going to fire that off and we're going to see what we get back and what I get back is indeed the

190
00:15:23,940 --> 00:15:28,290
user data which means I must have authenticated correctly.

191
00:15:28,290 --> 00:15:30,480
Let's go ahead and mess this token up.

192
00:15:30,540 --> 00:15:33,600
What I'm going to do is add a an E right up front.

193
00:15:33,600 --> 00:15:35,780
Manipulating the token string.

194
00:15:35,970 --> 00:15:40,050
I'm going to send it off again in this token it should now be invalid.

195
00:15:40,050 --> 00:15:43,410
Let's go ahead and see if that's actually what happens.

196
00:15:43,470 --> 00:15:50,520
I click send I send it off and I get my please authenticate message with my 4 0 1 response.

197
00:15:50,520 --> 00:15:57,170
So only when we provide a valid token are we going to be able to actually access the given endpoint

198
00:15:57,540 --> 00:16:01,530
and this is going to allow us to lock down our data.

199
00:16:01,530 --> 00:16:07,320
Now we still have plenty of routes that are and authenticated but before we go let's turn our attention

200
00:16:07,320 --> 00:16:11,770
back towards the one route that actually has authentication set up.

201
00:16:11,800 --> 00:16:13,700
There's a problem with this request.

202
00:16:13,710 --> 00:16:18,020
And the problem is that it exposes the data for other users.

203
00:16:18,030 --> 00:16:22,430
Now you do have to be authenticated but that's still not something we want to do.

204
00:16:22,500 --> 00:16:28,440
If a user is logged in they shouldn't be able to see the e-mail address of every other user who signed

205
00:16:28,440 --> 00:16:29,780
up for the app.

206
00:16:29,790 --> 00:16:34,770
Now we added this root to experiment with the basic structure of the rest api.

207
00:16:34,890 --> 00:16:39,360
But when it comes to the user's resource this is not something we want to support.

208
00:16:39,420 --> 00:16:41,750
Now we'll still support it for tasks.

209
00:16:41,760 --> 00:16:48,270
You'll be able to fetch multiple tasks but once we add authentication it'll be just tasks that you've

210
00:16:48,270 --> 00:16:52,590
created not every task in the database with users.

211
00:16:52,590 --> 00:16:56,130
There's gonna be no way to fetch other users data.

212
00:16:56,190 --> 00:17:02,370
So this route actually doesn't serve any purpose anymore but we are going to repurpose it for something

213
00:17:02,370 --> 00:17:09,210
that will exist in the final version of our app and that is a way to get your own profile to get the

214
00:17:09,210 --> 00:17:13,200
profile for the currently authenticated user.

215
00:17:13,320 --> 00:17:19,530
The route for this will still be get since we're getting data and it's going to be a forward slash users

216
00:17:19,590 --> 00:17:21,880
forward slash me.

217
00:17:21,900 --> 00:17:28,020
This is going to allow someone to get their own profile and there's no need to provide the I.D. for

218
00:17:28,020 --> 00:17:33,150
your own user as the authentication token has that information embedded.

219
00:17:33,150 --> 00:17:39,540
Now we can go ahead and remove everything we have in the function and all we need to do is send back

220
00:17:39,540 --> 00:17:41,280
that user profile.

221
00:17:41,310 --> 00:17:48,540
Now when we created the off middleware we assigned that to request dot user and we know that this function

222
00:17:48,540 --> 00:17:54,660
is only going to run if the user is actually authenticated which means that right here all we need to

223
00:17:54,660 --> 00:18:01,600
do is use response dot send to send back request dot user.

224
00:18:01,710 --> 00:18:02,850
And there we go.

225
00:18:02,880 --> 00:18:08,200
We now have a route that allows a user to get their profile when they're authenticated.

226
00:18:08,220 --> 00:18:11,520
Let's go ahead and save the program and actually test this out.

227
00:18:11,520 --> 00:18:19,140
So over in man we have the request that's no longer going to exist read users right here in this dot

228
00:18:19,140 --> 00:18:20,450
dot dot menu.

229
00:18:20,490 --> 00:18:22,230
I can rename that.

230
00:18:22,230 --> 00:18:29,270
I'll have it say something like read profile and then up above we'll just change that you are out from

231
00:18:29,270 --> 00:18:34,570
forward slash users to forward slash users forward slash me.

232
00:18:34,610 --> 00:18:40,250
Now if I fire this off instead of getting an array of users back I should just get back an individual

233
00:18:40,250 --> 00:18:43,730
user and that is exactly what's happening down below.

234
00:18:43,730 --> 00:18:50,060
I have my user profile the user who I'm currently logged in at.

235
00:18:50,270 --> 00:18:56,090
So now that we've seen how we can set up end points that have authentication we're going to continue

236
00:18:56,090 --> 00:18:59,120
on adding authentication throughout the application.

237
00:18:59,120 --> 00:19:02,900
Now in this video we just got the barebones setup in place.

238
00:19:02,900 --> 00:19:09,050
We're going to talk a lot more about headers authorization and bearer a little bit later in the class

239
00:19:09,230 --> 00:19:11,480
but for now everything is indeed working.

240
00:19:11,480 --> 00:19:13,600
Let's take a quick moment to recap.

241
00:19:13,700 --> 00:19:19,280
The first thing we did is we set up a middleware function to run for this specific route to the route

242
00:19:19,330 --> 00:19:22,020
that we want to lock down with authentication.

243
00:19:22,040 --> 00:19:25,090
We passed the middleware function in as the second argument.

244
00:19:25,100 --> 00:19:27,680
And the root handler in as the third.

245
00:19:27,680 --> 00:19:33,700
Now the middleware function itself starts by looking for the header that the user is supposed to provide

246
00:19:33,730 --> 00:19:39,520
and then validates that header and it finds the associated user from there.

247
00:19:39,530 --> 00:19:42,860
One of two things happen either we call next.

248
00:19:42,890 --> 00:19:49,280
Letting the root handler run or if they're not authenticated we go ahead and send back an error letting

249
00:19:49,280 --> 00:19:54,200
them know that they're not able to perform the operation that they're trying to perform.

250
00:19:54,200 --> 00:19:57,200
I'm very excited to continue on with authentication.

251
00:19:57,260 --> 00:19:59,540
So let's jump right in to the next video.