In the last video we had a long discussion about using cookies for authentication inside of our application.
We went through this entire diagram but there is one part that we seem to just very quickly skim over
and that was this very initial log in request.
In the last video we had said that the browser would make some requests that says hey log me in please.
And then the server responds back and says OK you're logged in and it seemed like there was just no
friction there whatsoever.
But you and I know that the real world doesn't behave like that in the real world.
Whenever we we want to sign in to an application we have to provide an e-mail password combination or
we have to go through some sort of a waterflow.
So in this video we're going to talk about how we're going to use the waterflow to really log in or
sign in a user to our application.
We're going to do this by first talking about how it works with e-mail password combinations and then
we'll kind of pivot and talk about how it's going to work with the overflow.
The reason that we're going to first talked about how it works with e-mail password combinations is
that I think that it makes a lot more sense to understand that way.
And once you kind of understand and internalize how e-mail password authentication is done it's a lot
easier to understand the similar process on your site.
OK.
So that's the idea.
Now there's one last thing that I want to talk about before we dive into all this.
Just a quick editor's note.
I'm going to say that this is going to probably be a pretty long video.
It's going to be divided into two halfs in the first half we're going to do kind of a high level overview
on how we use.
Off to log users then we'll then do like a quick pause and by pause I mean like I will tell you this
is our pause and then we're going to go through the entire process again.
But in much much greater detail and really lay out the steps that we're going to have to do inside of
our application to build this out.
Now the reason that I'm telling you this ahead of time is again this is Gimme a long video.
So if you just want to get the high level overview and then skip onto the implementation.
I will tell you like halfway through the video OK we're done with a high level overview and then you
can skip on if you want to.
So I just want to give you the option of getting through all this lecture stuff quickly if you don't
really care about it.
OK.
So let's get to it.
So again first we're going to talk about what it really means to sign into an application with an email
and password.
And we're going to take that understanding and apply it to the world.
So here's our diagram we're going to start off at the very top of this timeline.
And then as the diagram goes down time is passing.
So at the very start of the timeline we're going to imagine that some user comes to our application
and signs up to it with an e-mail and a password.
We say OK great e-mail password you are now signed in.
Thank you for signing up to our application for the first time.
We then take that e-mail password combination and we essentially just write it down somewhere right
on our server.
We just write it down and keep it around.
We can then imagine that some time goes by and then eventually our user signs out of the application
some more time passes and then the user comes back again and attempts to log in again.
Now the second time the user comes back here they are going to be providing us the exact same e-mail
and password combination.
Then on our server we can imagine that we would compare these to e-mail password combinations.
And if they are identical we can then confidently say OK great you must be the exact same person who
signed up originally.
Welcome back.
And then we would go ahead give the user the cookie and blah blah blah they can do all that other stuff.
Now again I'm talking about this e-mail password flow because I think it makes a lot of sense.
The identifying piece of information like the critical security credential is the fact that you are
always giving us the same e-mail and password again and again.
Now let's take that kind of flow and try to apply it to the world.
So over in the old world we do not have the benefit of any type of e-mail password.
So how are we going to like do a come do some comparison here and say that this is the same person who
had signed it previously.
Well let's go to the flow and see if we can't figure this out.
So again we're going to start up at the top we're going to say that a user signs up to our application
for the very first time they go through the overflow.
They then get directed to our server where we receive their google profile and we saw that just a moment
ago.
Remember we cancel logged out the Google profile.
So here it is right here.
So we've got the profile.
It's got the display name the name the e-mail all that kind of good stuff.
So we got that profile back from Google.
We can then imagine that the user signs out and then they come back through the log and flow again or
the overflow again.
Now when they click on that log into Google a second time they still go through the exact same lot flow.
So they still get redirected over to Google.
They still come back with a code.
We exchange that code for a profile.
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
decide whether or not this person who had previously signed up to our application is now the exact same
one who is coming back a second time.
So in the past with the e-mail password flow that we just spoke about we were able to say hey is e-mail
in power for the same.
Well great.
You must be the same person but this time around how are we going to pull that off.
Well I'm going to suggest that we picked some very consistent piece of information out of the profile
we will store that consistent piece of information and then every single time a user comes back and
logs into application and we receive that profile we'll say OK is this like one particular piece of
your profile identical to the previous time you came here because if it is you must be the exact same
user.
And so that's what we're going to do.
We're going to pick some very consistent piece of information to uniquely identify this user between
sign and attempts so what piece of identifying information is that.
Well let's look at the profile.
So here's a profile we get back from Google.
And inside of here you might see like say e-mails and here's e-mails and we've got the e-mail address
right here so you might be thinking well let's just use the e-mail and if a user comes in signs and
twice and they have the same e-mail must be the same person.
Well you know we could do that but remember how Google works.
Google allows you to associate as many e-mail addresses with your account as you wish.
So it's entirely conceivable that over time this Google user right here you know me might not have the
exact same e-mail again.
And so if we were using this e-mail address as the very unique identifying token and then I lost access
to the e-mail.
Poof all of a sudden a user cannot sign into our application again.
So rather than using this e-mail address right here we're going to instead use the user's I.D. right
up here at the very top of the profile.
So this I.D. property is Google's I.D. for this particular user this I.D. is never going to change over
time.
It's always going to be the exact same I.D..
So if we say that a user signs up for application on the very first time around we take that Google
profile we take the I.D. out of it and then we say fantastic.
You are now signed in then when the user comes back your application again and we get the Google profile
again.
We're going to take the I.D. out a second time.
Compare it to the original and say OK looks like the IDs are the same.
You must be the same person.
Welcome back.
So the entire key here around the flow is that it's only service to us it's only purpose is to give
us this one little unique identifying token and we can trust and believe that this is the same person
every single time.
Because you and I are essentially placing our trust in Google and we are assuming that Google is never
going to change this ID right here.
Now you might say Well Stephen what happens if Google changes that ID.
The answer is yeah we would then be completely screwed.
That is how it works.
We are placing our trust for authentication side of our application on a third party.
In this case Google.
So we are making the assumption that this I.D. will not change.
OK.
So at this point we have now reached like the halfway point we have established that to sign a user
in and signing user up inside of our application.
The only real piece of information that we care about out of that profile is the is the Google User
ID.
So now we understand that if you want to if you're tired of all these lectures you can pause the video
right now.
Continue in the next section where we will start to talk about the implementation of this flow.
Otherwise if you want to hear a very good and in-depth behind the scenes preview on what we're going
to do and obviously I really really really highly recommend you stick around then stay and we'll go
through it right now.
OK.
So let's do this.
So we're going to go back to this diagram that we're just looking at a second ago but we're going to
kind of expand on it and add a couple of additional steps.
Okay.
So again essentially same diagram but this time around a lot more detail.
So let's zoom in.
Okay.
So we're going to start up at the very top left again and we're going to go through the same flow with
a couple of extra steps.
So we start up here and we imagine that the user is coming to our server with a Google profile.
Now you and I know that it's really our server that takes the code from the user and then exchanges
that code for the profile.
But for the sake of discussion let's say the user comes to our server with some profile and they are
saying hey sign me up please.
So our server is going to take this user's profile.
They'll say Oh great a brand new user welcome.
We're going to create a new record inside of our database to record the fact that you user with google
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.
We will then reach over to our Mongo divi database which we have not yet spoken about at all.
Don't worry we'll talk about Mongo D-B a lot.
We're going to have a big old list of users over there and we will create a new user record which we
will imagine is user number one to three right here after we create this user.
We will then come back to the server say OK we've got a record inside of our database that says you
have signed up here before and you have been around.
We will then take a cookie.
Place that record of user 2:59 inside of it and then send that cookie back to the user's browser.
So now the user can make any sort of follow up request that they want and whenever that request comes
in we will see that cookie that says they are user 2:59 like this very particular person right here.
So we can imagine that maybe then the user creates a couple of surveys inside of our application and
then eventually they decide to log out.
So they click the log out button.
When that happens our server says OK yeah you know we understand you want to log out we are going to
on set or invalidate or expire the cookie.
So essentially we respond back and say OK cookie is now invalid you are logged out of the application.
And now here's the critical part.
We now imagine that the user comes back to our application again.
So they click on that log in with Google button.
They then go to Google.
They go through that entire flow again.
Remember every time they want to sign into application they always go through that Google flow.
So they go over to Google.
They get redirected back to a server with the profile.
And so this time around with the profile we take the profile.
But this time we say you know what I would like to make you a new user record but you might have been
here in the past.
So tell you why rather than just go ahead and make you a new user account.
Let's check to see if we've already got a record of a user with your very particular Google User ID.
So we go through our big list of users and eventually we find user 1 to 3 who internally inside of user
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
OK you know what we look to see if you've ever been here before.
And in fact you have your user 1 2 3.
So we go back to our server.
We say you've already been here before your user 1 2 3.
We do not have to create a new record for you.
And so we then again give the user a cookie that says you are user 2:59.
OK.
So that is like the very in-depth flow of what is happening behind the scenes.
Now to be really clear on one thing I had said at the very first time a user comes to our server from
Google we are going to just instantly create a new user that's not entirely accurate.
The flow down here is a little bit more accurate.
I only said yeah we were going to instantly create a new user just for the sake of discussion in reality
any time ever a user comes to us from Google we will assume that they might have already signed up to
our application.
So before we ever create any record of any user inside of our Mongo D-B database will always go in look
through all of our different records and see if the user with this very particular Google I.D. has been
here before.
And of course if they haven't if they've never been here before and we do find no record no problem
we'll go ahead and create a new record for them.
OK.
So at this point you might be thinking oh my gosh what did I get myself into with this course.
Hopefully not saying that.
You know hopefully this is all still fun and good.
Like I said previously you know a little bit of a pep talk.
This is the stuff you got to know to understand how this stuff works.
You got to understand this you can't just skirt your way around it forever and that's why you're here
taking this course.
So now that we've gone through this entire process and we've got a better idea of how authentication
is going to work inside of our application we're going to take a break.
We're going to come back in the next section and start to implement this flow.
Now the very first thing we're going to do in the next section is start to set up this Mongo DB database
because obviously the very critical part in here for identifying users who are coming back to our application
is the ability to store a list of users inside of our database.
So if nothing else inside this section I really just want you to understand that the purpose of a law
is just to give us this one tiny little identifying token just that Google I.D. nothing else.
That is all we care about we just care about this little google id right here because this is what proves
that a user is who they say they are.
Everything else about the user everything else will all be details that we store inside of our database.
OK.
So anyways let's take a break.
We're going to come back the next section.
We're going to do a quick talk about the basics of Mongo D.B and then we'll start to integrate it into
our application so I'll see you in just a sec.