I think that we've now got a pretty good idea of how re-act router Dohm works inside of application
and we've also written out a pretty good amount of code to set up some initial idea around navigation.
So we're not going to start to pivot our attention and focus on handling authentication inside of our
app.
In this video we're going to have a general discussion on how we handle authentication in general like
any type of web application and then we will very quickly start to talk about how we're going to work
it specifically into a react and redux application.
So let's get to it.
All right.
So first off the idea here is that inside of her head her we're going to have some button that says
something like log in with Google to handle authentication.
We're going to use Google's off to authentication flow.
I can almost guarantee you that you have gone through a lot flow before in your own experience.
So any time that you ever click on some button like log in with Google or log in with Facebook or logging
into LinkedIn that is you going through a lot 2.00 flow the pinnacle or the very traditional screen
that you see anytime you go through a lot.
Flow is someone window like this over here is something that says hey this application wants to know
your e-mail address or access your profile or whatever else it might be.
And then you as a user can either accept or reject that request.
So in this video we're going to get a better idea of what it really is and how the flow works.
Let's get to it.
All right.
So in many applications that you've used You've probably also seen e-mail and password authentication.
Even Google itself when you sign into Google or Facebook you have to use e-mail and password authentication
with this very classic form about an occasion over here.
We generally store a record inside of some type of database and that record is going to maintain the
user's e-mail address and their encrypted password.
And so with email and password authentication you're essentially inside of your own application or maintaining
a record of who each user is.
And you have some very intricate and detailed information about each and every user and each time that
a user tries to log in with email and password authentication we're essentially going to take and compare
the e-mails entered e-mail and password with whatever is saved inside the database.
And then a user is considered to be logged in to an application whenever they enter the correct email
and password.
So again that is traditional email and password authentication.
So let's kind of compare that kind of easier or more traditional sense of authentication with Olof authentication
which is what you and I are going to use.
So with authentication a user is going to first authenticate with some outside service provider through
email and password authentication means an outside service provider is any provider such as Google or
LinkedIn or Facebook as very popular examples.
Now with this flow we are essentially getting a user to authorize our application to access their information
stored on Google's or LinkedIn or Facebook servers.
So this outside provider is going to essentially tell us some information about this user such as their
email their name or whatever other info you and I request.
So we are really trusting this outside provider quite a bit to identify this user and we are absolutely
trusting this outside provider that they are telling us correct information here.
A good analogy here is to imagine if you are running some type of like lottery operation like lets say
you put a lottery together and someone comes through your door inside of your office and says Hey I
just won the lottery Ive got a winning ticket.
If you are the lottery provider and youre running this lottery chances are the first thing you want
to do is make sure that this person is who they say they are right.
You want to make sure that they are so and so and that they actually won the lottery with that ticket
in hand.
And so you can either kind of take that person's identification like maybe a driver's license or something
like that.
Or if that person has some friend who will vouch for them it would be like you trusting that friend
to say oh yes this person is who they say they are.
So with email and pass TROETH indication that is like you collecting credentials on your own like some
identification for the user.
Whereas with authentication we are essentially trusting some friend of that person saying that they
are who they say they are now with Oh.
It's really a kind of two sided thing that we get with off with email and password authentication this
is solely about authentication.
It is just about identifying a user and associating some information with them or with oh off we actually
get kind of two results out of this flow.
On the one hand we still get that same type of user identification inside of application.
So when the user goes through the flow we get some information that says oh yeah this is Jane Doe and
this is their email address and here is their picture or whatever it is.
But with the flow we also can request access to make actions on behalf of the user through that service
provider.
Now classic examples of that would be like if we put together some application that wanted to manage
a user's e-mail account like maybe filter their emails or try to read their emails.
We would use a lot flow to get access to that user's e-mail account.
So Olaf is not only about authentication it's also about letting our application get access to all that
user's data on some outside service provider.
Now in our case we're only concerned about use case number one here.
We are just making use of oath to identify a user we are not going to use cloth to try to like make
actions on behalf of the user and try to access Google services.
Now on that note on that.
Number two right there.
Very common question that I get is how do you use a watch to do that.
You know how do you actually use this offload to make actions or requests over to Google on behalf of
a user.
Just so you know as a quick side topic here every time that you go through a lot flow its eventually
is going to say something like Hey this Apple wants to know your e-mail access your profile maybe it
will also say read your browser history or access all of your e-mails or whatever else that might be
a list of things that the app wants to do is known as its list of scopes.
A scope is essentially a permission that you are granting to an application.
Now with Google in particular you can get a list of all valid scopes at this address right here.
Now keep in mind google very frequently changes.
You are or else.
So by the time you watch this video this link right here might be broken if that link is broken you
can always do a very simple Google search for something like Google.
Olof I don't know.
Scope list or something like that and you should see something like this right here on Earth 2.0 scopes
for Google API is so on this page is a list of all the different scopes that you can ask for.
And each of these different scopes are going to give you access to a different portion of the users
account.
Now in our case the only thing that you and I really care about is probably going to be like a user's
e-mail just so we can confirm that they are who they say they are and that we have some piece of information
too tied to a user.
So in our application we are probably going to ask for a scope of email somewhere inside of here.
We go.
So here's the list of scopes for Google sign in.
We can ask for a user's e-mail or their profile very easily and get the e-mails or the user's email
address or their basic profile info.
So we would use a scope named profile or email to get access to those two pieces of information if we
had asked for a scope of something like I don't know about this one right year.
So Google API is dot com slash off cloud platform that would allow us to manage the user's data across
all Google Cloud platform services or what have you if we wanted to access their email.
We would probably do a search on this page for Gmail like this right here.
And this is a list of scopes that we could ask for to get access to the user's e-mails so if we ask
for this scope right here then we would get the ability to read compose send in primally deletes all
email from G-mail.
And one thing I would make clear is that this scope is intended to be a string like a string value that
we are going to pass over to Google when we go through the overflow.
The scope even though it looks like a r l is not something that you're going to like add into your address
bar.
Let's talk more about scopes later on.
But like I said this is a very common question I get.
So I just want to very quickly give you a heads up on how you would kind of get access to a user's account.
All right.
So back over here a diagram.
Now if you've ever gone through one of my other courses before I have many courses that make use of
Google off and just about every Google overflow that I show and every single other course makes use
of a wealth for servers in this course for the first time ever.
So if you've gone through all that with me before this time it's going to be a little bit different.
So this is the first I'm going to show you how to do a lot for javascript browser apps or some javascript
code that is running inside the browser.
And so there's a little difference between these two flows right here.
Let's take a quick pause.
When we come back the next section I'll describe the differences between the two and how it's going
to affect how our application is set up.
So quick break and I'll see you in just a minute.