In the last section we were able to test out a little bit more inside of our authentication flow and
at the very end we saw that presumably at the terminal some access token or something like that got
console logged out.
Inside this section we're going to figure out a little bit more about what this access token is what
the purpose of this arrow function is at at all and exactly where we are inside of our authentication
flow.
So we're going to first address that third item.
We're going to figure out where we are inside of our flow.
It's always important to look back to this diagram to have a really good sense of what's going on.
So at this point we have redirected our user over to Google.
They granted us permission.
We got sent back to localhost 5000 slash slash school slash callback.
The passport strategy saw the code inside of the your L and automatically did a follow up request over
to Google to exchange that code with the user's actual profile and e-mail address.
After that follow up request is made the callback function that arrow function.
The second argument to the Google strategy was executed.
So this arrow function right here is our opportunity to take all the information that we just got back
from Google like the actual user's profile and that access token which we'll talk about in just a second.
That's our opportunity to now create a new user inside of our database that says hey here's this person
they have signed up before using Google.
They now have access to our application and they can create surveys and all that kind of good stuff
inside of our app.
So this arrow function is our opportunity to now take this identifying user information and save it
to our database if we want to get a better sense of exactly what is happening inside this aero function.
We're going to add on a couple more arguments and then console log them all out and that will give us
a little bit of a better idea of what's going on inside of you.
So I'm going to put a set of parentheses around the access token argument because we want to get a couple
of other arguments out of here as well.
We're going to also take an argument called refresh tokin profile and done.
And then inside of the body of this function we're going to cancel log out the access token.
I'm going to add a little string here to just mark each thing that we're con. logging.
We're going to cancel log the refreshed token
and then we'll also cancel log out the profile.
OK.
So we're now going to go through our a lot flow one more time.
And when we come back to our server we should see all these council logs kick in and then we can kind
of inspect some of the information that we're working with in our side of this callback.
So one last thing we have to do.
Remember any time that we change our code right now we have to restart our server.
We will fix that up very shortly.
So we don't have to do that.
Now if your server is still running you can stop it by pressing control C on your keyboard and that
should kill the server.
So once you've killed the server will then start it back up with node index stock.
Yes.
OK.
So it's now running.
We're now going to run through our waterflow.
One more time and then check out those console logs.
So inside of a new browser tab going to visit localhost Kulin 5000 slash Auth. slash Google.
Now remember at this point in time we have already given Google access to our account so we might just
instantly kind of get redirected back over to our server and the browser will seem to just hang again.
Now if that happens to you that's totally fine.
So I'm going to go to local shows 5000 Google and again you can tell right now it looks like everything
is just hanging.
But all that means is that we have previously given this application access to our profile and so Google
is really not asking us to grant permission or select account or anything like that anymore.
Google is just saying Oh you've already been here you've already granted permission.
OK.
Just go right back to the server.
And so that's why as soon as we put that you are Ellen It seems like everything is just happening right
now.
The request is pending on our server and it's waiting for us to do something.
OK so at this point this callback function should have been executed because remember it is called the
instant that the user gets sent back to our server and we exchange that code for some identifying information.
So now if we go back to our terminal we'll see those three console logs that we put in.
So if I scroll up a little bit you'll see the console log for access token.
So here's the access token here's the refresh token which is undefined.
And then here is our profile information which contains all the identifying information for this particular
user.
So here is my display name my family name a list of all my different email addresses.
My profile picture gender all this other kind of stuff that we might want to get access to inside of
our application.
So this is pretty much it.
This is the heart of what we're getting at right here.
This is our identifying information now really quickly on the access token and the refreshed token.
First off the access token if we had asked for permission to read say the users e-mail contact list
or read all of their e-mails or anything like that kind of like do something on the user's behalf or
kind of modify their account in some fashion.
That is the purpose of this access token right here.
It is a token that essentially allows us to reach back over to Google and say hey in the past this user
said that we could read their profile or that we could add or delete emails inside or out inside their
e-mail inbox.
Here's the access token that proves that we are allowed to do that.
And so it's access token access token excuse me is pretty important but we're not really using it for
anything inside our application.
So we're not going to be terribly concerned with it.
Now the refreshed token right here would allow us to refresh the access token the access token automatically
expires after some amount of time and we can be given optionally a refreshed token that allows us to
automatically update the access token and essentially reach into the users account for some additional
amount of time.
Now again we're not making use of the access token so we don't really care about the refresh won at
all either.
Finally the profile which we just spoke about it has all of our actual identifying information.
And so this is the thing that we really care about right here.
OK.
So we've definitely made some progress.
We've got access to all the users information but at this point it's kind of like well that's great
but what are we doing with it.
So at this point we have really concluded with the passport side of our application more or less kind
like we'll say kind of we that at least finished up with these steps right here.
And so at this point it's now up to us to create a new record inside of our database and then kind of
like do some magic stuff to make this user considered to be logged into our application.
Now these last steps right here are like a whole gigantic can of worms.
So in this section we're going to kind of say that phase one of our authentication flow is complete
and in the next section we're going to start to move onto some stuff working around with databases and
figuring out what authentication really really means inside of our application.
So let's take a quick break.
When we come back in the next section we're going to start to kick off the next phase of authentication
inside of our app.
So I'll see you in just a second.