1
00:00:00,660 --> 00:00:06,510
In the last video we had a long discussion about using cookies for authentication inside of our application.

2
00:00:06,510 --> 00:00:11,910
We went through this entire diagram but there is one part that we seem to just very quickly skim over

3
00:00:12,360 --> 00:00:16,330
and that was this very initial log in request.

4
00:00:16,350 --> 00:00:21,880
In the last video we had said that the browser would make some requests that says hey log me in please.

5
00:00:21,930 --> 00:00:27,300
And then the server responds back and says OK you're logged in and it seemed like there was just no

6
00:00:27,300 --> 00:00:28,980
friction there whatsoever.

7
00:00:28,980 --> 00:00:33,050
But you and I know that the real world doesn't behave like that in the real world.

8
00:00:33,060 --> 00:00:39,210
Whenever we we want to sign in to an application we have to provide an e-mail password combination or

9
00:00:39,210 --> 00:00:41,790
we have to go through some sort of a waterflow.

10
00:00:41,790 --> 00:00:48,480
So in this video we're going to talk about how we're going to use the waterflow to really log in or

11
00:00:48,480 --> 00:00:51,540
sign in a user to our application.

12
00:00:51,630 --> 00:00:56,760
We're going to do this by first talking about how it works with e-mail password combinations and then

13
00:00:56,760 --> 00:01:01,640
we'll kind of pivot and talk about how it's going to work with the overflow.

14
00:01:01,650 --> 00:01:05,370
The reason that we're going to first talked about how it works with e-mail password combinations is

15
00:01:05,370 --> 00:01:08,760
that I think that it makes a lot more sense to understand that way.

16
00:01:08,820 --> 00:01:13,980
And once you kind of understand and internalize how e-mail password authentication is done it's a lot

17
00:01:13,980 --> 00:01:17,620
easier to understand the similar process on your site.

18
00:01:17,900 --> 00:01:18,510
OK.

19
00:01:18,840 --> 00:01:20,030
So that's the idea.

20
00:01:20,040 --> 00:01:23,410
Now there's one last thing that I want to talk about before we dive into all this.

21
00:01:23,430 --> 00:01:24,910
Just a quick editor's note.

22
00:01:24,930 --> 00:01:28,140
I'm going to say that this is going to probably be a pretty long video.

23
00:01:28,410 --> 00:01:33,630
It's going to be divided into two halfs in the first half we're going to do kind of a high level overview

24
00:01:33,900 --> 00:01:34,840
on how we use.

25
00:01:34,910 --> 00:01:41,940
Off to log users then we'll then do like a quick pause and by pause I mean like I will tell you this

26
00:01:41,940 --> 00:01:45,600
is our pause and then we're going to go through the entire process again.

27
00:01:45,690 --> 00:01:50,040
But in much much greater detail and really lay out the steps that we're going to have to do inside of

28
00:01:50,040 --> 00:01:51,990
our application to build this out.

29
00:01:51,990 --> 00:01:55,840
Now the reason that I'm telling you this ahead of time is again this is Gimme a long video.

30
00:01:55,980 --> 00:02:00,480
So if you just want to get the high level overview and then skip onto the implementation.

31
00:02:00,480 --> 00:02:05,040
I will tell you like halfway through the video OK we're done with a high level overview and then you

32
00:02:05,040 --> 00:02:06,590
can skip on if you want to.

33
00:02:06,600 --> 00:02:10,980
So I just want to give you the option of getting through all this lecture stuff quickly if you don't

34
00:02:10,980 --> 00:02:12,150
really care about it.

35
00:02:12,590 --> 00:02:12,940
OK.

36
00:02:12,990 --> 00:02:14,690
So let's get to it.

37
00:02:14,700 --> 00:02:19,380
So again first we're going to talk about what it really means to sign into an application with an email

38
00:02:19,380 --> 00:02:20,220
and password.

39
00:02:20,340 --> 00:02:23,990
And we're going to take that understanding and apply it to the world.

40
00:02:24,000 --> 00:02:28,530
So here's our diagram we're going to start off at the very top of this timeline.

41
00:02:28,740 --> 00:02:31,950
And then as the diagram goes down time is passing.

42
00:02:32,250 --> 00:02:36,810
So at the very start of the timeline we're going to imagine that some user comes to our application

43
00:02:37,020 --> 00:02:40,000
and signs up to it with an e-mail and a password.

44
00:02:40,230 --> 00:02:43,560
We say OK great e-mail password you are now signed in.

45
00:02:43,560 --> 00:02:46,850
Thank you for signing up to our application for the first time.

46
00:02:46,890 --> 00:02:51,750
We then take that e-mail password combination and we essentially just write it down somewhere right

47
00:02:52,320 --> 00:02:53,090
on our server.

48
00:02:53,090 --> 00:02:55,810
We just write it down and keep it around.

49
00:02:55,980 --> 00:03:00,930
We can then imagine that some time goes by and then eventually our user signs out of the application

50
00:03:01,620 --> 00:03:06,940
some more time passes and then the user comes back again and attempts to log in again.

51
00:03:06,960 --> 00:03:14,080
Now the second time the user comes back here they are going to be providing us the exact same e-mail

52
00:03:14,100 --> 00:03:16,150
and password combination.

53
00:03:16,230 --> 00:03:22,980
Then on our server we can imagine that we would compare these to e-mail password combinations.

54
00:03:23,210 --> 00:03:31,110
And if they are identical we can then confidently say OK great you must be the exact same person who

55
00:03:31,110 --> 00:03:32,340
signed up originally.

56
00:03:32,340 --> 00:03:33,630
Welcome back.

57
00:03:33,630 --> 00:03:39,540
And then we would go ahead give the user the cookie and blah blah blah they can do all that other stuff.

58
00:03:39,540 --> 00:03:44,570
Now again I'm talking about this e-mail password flow because I think it makes a lot of sense.

59
00:03:44,640 --> 00:03:50,880
The identifying piece of information like the critical security credential is the fact that you are

60
00:03:50,880 --> 00:03:55,140
always giving us the same e-mail and password again and again.

61
00:03:55,530 --> 00:04:01,250
Now let's take that kind of flow and try to apply it to the world.

62
00:04:01,260 --> 00:04:07,150
So over in the old world we do not have the benefit of any type of e-mail password.

63
00:04:07,200 --> 00:04:13,410
So how are we going to like do a come do some comparison here and say that this is the same person who

64
00:04:13,410 --> 00:04:14,830
had signed it previously.

65
00:04:14,880 --> 00:04:17,320
Well let's go to the flow and see if we can't figure this out.

66
00:04:17,670 --> 00:04:21,810
So again we're going to start up at the top we're going to say that a user signs up to our application

67
00:04:21,810 --> 00:04:25,940
for the very first time they go through the overflow.

68
00:04:26,160 --> 00:04:31,950
They then get directed to our server where we receive their google profile and we saw that just a moment

69
00:04:31,950 --> 00:04:32,220
ago.

70
00:04:32,280 --> 00:04:34,510
Remember we cancel logged out the Google profile.

71
00:04:34,530 --> 00:04:35,900
So here it is right here.

72
00:04:35,940 --> 00:04:37,260
So we've got the profile.

73
00:04:37,350 --> 00:04:41,330
It's got the display name the name the e-mail all that kind of good stuff.

74
00:04:43,330 --> 00:04:46,120
So we got that profile back from Google.

75
00:04:46,120 --> 00:04:51,640
We can then imagine that the user signs out and then they come back through the log and flow again or

76
00:04:51,640 --> 00:04:53,270
the overflow again.

77
00:04:53,350 --> 00:05:01,110
Now when they click on that log into Google a second time they still go through the exact same lot flow.

78
00:05:01,360 --> 00:05:03,600
So they still get redirected over to Google.

79
00:05:03,640 --> 00:05:05,720
They still come back with a code.

80
00:05:05,740 --> 00:05:07,770
We exchange that code for a profile.

81
00:05:07,840 --> 00:05:14,800
And now all of a sudden here we are again with a Google profile in hand and it's now up to us to somehow

82
00:05:14,800 --> 00:05:20,560
decide whether or not this person who had previously signed up to our application is now the exact same

83
00:05:20,560 --> 00:05:23,350
one who is coming back a second time.

84
00:05:23,350 --> 00:05:28,600
So in the past with the e-mail password flow that we just spoke about we were able to say hey is e-mail

85
00:05:28,600 --> 00:05:29,670
in power for the same.

86
00:05:29,720 --> 00:05:30,270
Well great.

87
00:05:30,280 --> 00:05:35,260
You must be the same person but this time around how are we going to pull that off.

88
00:05:35,620 --> 00:05:43,000
Well I'm going to suggest that we picked some very consistent piece of information out of the profile

89
00:05:43,450 --> 00:05:49,540
we will store that consistent piece of information and then every single time a user comes back and

90
00:05:49,540 --> 00:05:55,480
logs into application and we receive that profile we'll say OK is this like one particular piece of

91
00:05:55,480 --> 00:06:01,480
your profile identical to the previous time you came here because if it is you must be the exact same

92
00:06:01,480 --> 00:06:02,280
user.

93
00:06:02,380 --> 00:06:03,400
And so that's what we're going to do.

94
00:06:03,400 --> 00:06:08,870
We're going to pick some very consistent piece of information to uniquely identify this user between

95
00:06:08,870 --> 00:06:13,680
sign and attempts so what piece of identifying information is that.

96
00:06:13,760 --> 00:06:15,820
Well let's look at the profile.

97
00:06:16,100 --> 00:06:18,220
So here's a profile we get back from Google.

98
00:06:18,680 --> 00:06:24,980
And inside of here you might see like say e-mails and here's e-mails and we've got the e-mail address

99
00:06:24,980 --> 00:06:30,200
right here so you might be thinking well let's just use the e-mail and if a user comes in signs and

100
00:06:30,200 --> 00:06:33,440
twice and they have the same e-mail must be the same person.

101
00:06:33,890 --> 00:06:37,760
Well you know we could do that but remember how Google works.

102
00:06:37,970 --> 00:06:42,920
Google allows you to associate as many e-mail addresses with your account as you wish.

103
00:06:43,160 --> 00:06:50,240
So it's entirely conceivable that over time this Google user right here you know me might not have the

104
00:06:50,240 --> 00:06:51,960
exact same e-mail again.

105
00:06:52,190 --> 00:06:58,580
And so if we were using this e-mail address as the very unique identifying token and then I lost access

106
00:06:58,580 --> 00:06:59,240
to the e-mail.

107
00:06:59,270 --> 00:07:03,510
Poof all of a sudden a user cannot sign into our application again.

108
00:07:03,890 --> 00:07:11,360
So rather than using this e-mail address right here we're going to instead use the user's I.D. right

109
00:07:11,360 --> 00:07:13,860
up here at the very top of the profile.

110
00:07:13,940 --> 00:07:21,710
So this I.D. property is Google's I.D. for this particular user this I.D. is never going to change over

111
00:07:21,710 --> 00:07:22,060
time.

112
00:07:22,070 --> 00:07:25,620
It's always going to be the exact same I.D..

113
00:07:25,760 --> 00:07:31,670
So if we say that a user signs up for application on the very first time around we take that Google

114
00:07:31,670 --> 00:07:36,080
profile we take the I.D. out of it and then we say fantastic.

115
00:07:36,110 --> 00:07:41,240
You are now signed in then when the user comes back your application again and we get the Google profile

116
00:07:41,240 --> 00:07:41,830
again.

117
00:07:41,990 --> 00:07:45,080
We're going to take the I.D. out a second time.

118
00:07:45,080 --> 00:07:49,120
Compare it to the original and say OK looks like the IDs are the same.

119
00:07:49,160 --> 00:07:50,600
You must be the same person.

120
00:07:50,600 --> 00:07:52,340
Welcome back.

121
00:07:52,340 --> 00:07:59,420
So the entire key here around the flow is that it's only service to us it's only purpose is to give

122
00:07:59,420 --> 00:08:06,260
us this one little unique identifying token and we can trust and believe that this is the same person

123
00:08:06,290 --> 00:08:07,430
every single time.

124
00:08:07,580 --> 00:08:13,640
Because you and I are essentially placing our trust in Google and we are assuming that Google is never

125
00:08:13,640 --> 00:08:15,770
going to change this ID right here.

126
00:08:15,770 --> 00:08:19,870
Now you might say Well Stephen what happens if Google changes that ID.

127
00:08:20,120 --> 00:08:22,340
The answer is yeah we would then be completely screwed.

128
00:08:22,340 --> 00:08:23,320
That is how it works.

129
00:08:23,330 --> 00:08:24,530
That is how it works.

130
00:08:24,530 --> 00:08:30,220
We are placing our trust for authentication side of our application on a third party.

131
00:08:30,320 --> 00:08:31,550
In this case Google.

132
00:08:31,640 --> 00:08:35,680
So we are making the assumption that this I.D. will not change.

133
00:08:36,210 --> 00:08:36,640
OK.

134
00:08:36,710 --> 00:08:42,680
So at this point we have now reached like the halfway point we have established that to sign a user

135
00:08:42,680 --> 00:08:45,500
in and signing user up inside of our application.

136
00:08:45,650 --> 00:08:51,230
The only real piece of information that we care about out of that profile is the is the Google User

137
00:08:51,230 --> 00:08:52,020
ID.

138
00:08:52,340 --> 00:08:56,960
So now we understand that if you want to if you're tired of all these lectures you can pause the video

139
00:08:56,960 --> 00:08:57,740
right now.

140
00:08:57,740 --> 00:09:02,300
Continue in the next section where we will start to talk about the implementation of this flow.

141
00:09:02,300 --> 00:09:07,340
Otherwise if you want to hear a very good and in-depth behind the scenes preview on what we're going

142
00:09:07,340 --> 00:09:14,990
to do and obviously I really really really highly recommend you stick around then stay and we'll go

143
00:09:14,990 --> 00:09:15,940
through it right now.

144
00:09:16,300 --> 00:09:16,700
OK.

145
00:09:16,820 --> 00:09:18,360
So let's do this.

146
00:09:18,440 --> 00:09:22,850
So we're going to go back to this diagram that we're just looking at a second ago but we're going to

147
00:09:23,030 --> 00:09:27,470
kind of expand on it and add a couple of additional steps.

148
00:09:27,490 --> 00:09:27,810
Okay.

149
00:09:27,860 --> 00:09:33,470
So again essentially same diagram but this time around a lot more detail.

150
00:09:34,020 --> 00:09:35,370
So let's zoom in.

151
00:09:36,010 --> 00:09:36,530
Okay.

152
00:09:37,420 --> 00:09:41,320
So we're going to start up at the very top left again and we're going to go through the same flow with

153
00:09:41,320 --> 00:09:43,470
a couple of extra steps.

154
00:09:43,750 --> 00:09:49,780
So we start up here and we imagine that the user is coming to our server with a Google profile.

155
00:09:49,780 --> 00:09:54,370
Now you and I know that it's really our server that takes the code from the user and then exchanges

156
00:09:54,370 --> 00:09:55,670
that code for the profile.

157
00:09:55,750 --> 00:10:01,090
But for the sake of discussion let's say the user comes to our server with some profile and they are

158
00:10:01,090 --> 00:10:03,730
saying hey sign me up please.

159
00:10:03,730 --> 00:10:07,270
So our server is going to take this user's profile.

160
00:10:07,270 --> 00:10:10,930
They'll say Oh great a brand new user welcome.

161
00:10:10,960 --> 00:10:18,010
We're going to create a new record inside of our database to record the fact that you user with google

162
00:10:18,010 --> 00:10:26,260
id of 1 1 1 7 2 2 3 5 blah blah blah has come and signed up for an account inside of our application.

163
00:10:26,470 --> 00:10:31,300
We will then reach over to our Mongo divi database which we have not yet spoken about at all.

164
00:10:31,300 --> 00:10:33,790
Don't worry we'll talk about Mongo D-B a lot.

165
00:10:33,790 --> 00:10:39,100
We're going to have a big old list of users over there and we will create a new user record which we

166
00:10:39,100 --> 00:10:45,200
will imagine is user number one to three right here after we create this user.

167
00:10:45,340 --> 00:10:50,680
We will then come back to the server say OK we've got a record inside of our database that says you

168
00:10:50,680 --> 00:10:53,530
have signed up here before and you have been around.

169
00:10:53,590 --> 00:10:55,020
We will then take a cookie.

170
00:10:55,060 --> 00:11:01,170
Place that record of user 2:59 inside of it and then send that cookie back to the user's browser.

171
00:11:01,420 --> 00:11:07,300
So now the user can make any sort of follow up request that they want and whenever that request comes

172
00:11:07,300 --> 00:11:14,290
in we will see that cookie that says they are user 2:59 like this very particular person right here.

173
00:11:14,650 --> 00:11:19,840
So we can imagine that maybe then the user creates a couple of surveys inside of our application and

174
00:11:19,840 --> 00:11:22,390
then eventually they decide to log out.

175
00:11:22,390 --> 00:11:24,330
So they click the log out button.

176
00:11:24,640 --> 00:11:29,980
When that happens our server says OK yeah you know we understand you want to log out we are going to

177
00:11:30,050 --> 00:11:34,710
on set or invalidate or expire the cookie.

178
00:11:34,720 --> 00:11:40,320
So essentially we respond back and say OK cookie is now invalid you are logged out of the application.

179
00:11:40,600 --> 00:11:42,760
And now here's the critical part.

180
00:11:42,790 --> 00:11:45,820
We now imagine that the user comes back to our application again.

181
00:11:46,060 --> 00:11:49,080
So they click on that log in with Google button.

182
00:11:49,300 --> 00:11:50,580
They then go to Google.

183
00:11:50,590 --> 00:11:52,350
They go through that entire flow again.

184
00:11:52,360 --> 00:11:56,760
Remember every time they want to sign into application they always go through that Google flow.

185
00:11:57,100 --> 00:11:58,140
So they go over to Google.

186
00:11:58,180 --> 00:12:00,990
They get redirected back to a server with the profile.

187
00:12:01,300 --> 00:12:04,810
And so this time around with the profile we take the profile.

188
00:12:04,810 --> 00:12:12,460
But this time we say you know what I would like to make you a new user record but you might have been

189
00:12:12,460 --> 00:12:13,610
here in the past.

190
00:12:13,630 --> 00:12:18,000
So tell you why rather than just go ahead and make you a new user account.

191
00:12:18,160 --> 00:12:27,130
Let's check to see if we've already got a record of a user with your very particular Google User ID.

192
00:12:27,490 --> 00:12:34,660
So we go through our big list of users and eventually we find user 1 to 3 who internally inside of user

193
00:12:34,660 --> 00:12:45,200
1 2 3 right here inside of our Mongo D-B database has a google id of 1 1 7 2 2 3 5 so our server says

194
00:12:45,360 --> 00:12:48,530
OK you know what we look to see if you've ever been here before.

195
00:12:48,560 --> 00:12:51,600
And in fact you have your user 1 2 3.

196
00:12:51,950 --> 00:12:53,440
So we go back to our server.

197
00:12:53,450 --> 00:12:56,830
We say you've already been here before your user 1 2 3.

198
00:12:56,840 --> 00:12:59,300
We do not have to create a new record for you.

199
00:12:59,450 --> 00:13:04,610
And so we then again give the user a cookie that says you are user 2:59.

200
00:13:05,240 --> 00:13:05,780
OK.

201
00:13:05,870 --> 00:13:10,520
So that is like the very in-depth flow of what is happening behind the scenes.

202
00:13:10,670 --> 00:13:16,580
Now to be really clear on one thing I had said at the very first time a user comes to our server from

203
00:13:16,580 --> 00:13:22,340
Google we are going to just instantly create a new user that's not entirely accurate.

204
00:13:22,610 --> 00:13:25,200
The flow down here is a little bit more accurate.

205
00:13:25,280 --> 00:13:30,840
I only said yeah we were going to instantly create a new user just for the sake of discussion in reality

206
00:13:31,250 --> 00:13:38,270
any time ever a user comes to us from Google we will assume that they might have already signed up to

207
00:13:38,270 --> 00:13:39,660
our application.

208
00:13:39,770 --> 00:13:46,790
So before we ever create any record of any user inside of our Mongo D-B database will always go in look

209
00:13:46,790 --> 00:13:53,150
through all of our different records and see if the user with this very particular Google I.D. has been

210
00:13:53,150 --> 00:13:53,930
here before.

211
00:13:54,110 --> 00:13:58,580
And of course if they haven't if they've never been here before and we do find no record no problem

212
00:13:58,670 --> 00:14:01,150
we'll go ahead and create a new record for them.

213
00:14:01,740 --> 00:14:02,400
OK.

214
00:14:02,720 --> 00:14:09,960
So at this point you might be thinking oh my gosh what did I get myself into with this course.

215
00:14:10,400 --> 00:14:11,380
Hopefully not saying that.

216
00:14:11,420 --> 00:14:13,930
You know hopefully this is all still fun and good.

217
00:14:13,940 --> 00:14:16,460
Like I said previously you know a little bit of a pep talk.

218
00:14:16,490 --> 00:14:20,420
This is the stuff you got to know to understand how this stuff works.

219
00:14:20,420 --> 00:14:23,930
You got to understand this you can't just skirt your way around it forever and that's why you're here

220
00:14:23,930 --> 00:14:25,640
taking this course.

221
00:14:25,640 --> 00:14:31,480
So now that we've gone through this entire process and we've got a better idea of how authentication

222
00:14:31,480 --> 00:14:34,510
is going to work inside of our application we're going to take a break.

223
00:14:34,520 --> 00:14:38,350
We're going to come back in the next section and start to implement this flow.

224
00:14:38,660 --> 00:14:43,940
Now the very first thing we're going to do in the next section is start to set up this Mongo DB database

225
00:14:44,180 --> 00:14:50,480
because obviously the very critical part in here for identifying users who are coming back to our application

226
00:14:50,750 --> 00:14:55,300
is the ability to store a list of users inside of our database.

227
00:14:55,310 --> 00:15:01,760
So if nothing else inside this section I really just want you to understand that the purpose of a law

228
00:15:01,880 --> 00:15:09,080
is just to give us this one tiny little identifying token just that Google I.D. nothing else.

229
00:15:09,140 --> 00:15:14,480
That is all we care about we just care about this little google id right here because this is what proves

230
00:15:14,690 --> 00:15:16,650
that a user is who they say they are.

231
00:15:17,000 --> 00:15:22,870
Everything else about the user everything else will all be details that we store inside of our database.

232
00:15:23,370 --> 00:15:23,610
OK.

233
00:15:23,630 --> 00:15:25,160
So anyways let's take a break.

234
00:15:25,160 --> 00:15:26,820
We're going to come back the next section.

235
00:15:26,930 --> 00:15:32,300
We're going to do a quick talk about the basics of Mongo D.B and then we'll start to integrate it into

236
00:15:32,300 --> 00:15:35,470
our application so I'll see you in just a sec.