In the last section we tested out our flow but we really saw an error message that said redirect your
mismatch.
So we were kind of expecting this air or at least I told you to expect it let's take the opportunity
to kind of figure out what's going on.
And when we do we're going to get a better sense of what a lot is doing behind the scenes.
I'm going to take the or else that's in my address bar right now.
I'm going to copy it and then paste it inside my code editor so that we can kind of dissect this you
are Al just a little bit.
I'm going to turn on soft rap like so.
So here's the entire you are l.
Here's the bass you are l.
And then after that we've got a clearer string which contains some information about the flow that we're
kicking the user into.
Now to just make this a little bit more legible I'm going to add in a couple of new line characters
here.
After every property inside the query string OK.
So the very first property we have is the response code or the risks you excuse me the response type
and we're saying that we expect to get a code back.
Remember we had said that after the user grants permission to our application the user would be sent
back to her application with this code that we can use to exchange with Google to get some information
about the user's profile.
So after the user grant permission to us to read their account we don't immediately get sent back their
entire account and all the information tied to it or we get sent back.
Is that code which we can then use to make a follow up request to Google to ask for some more information
about this user.
So we are clearly asking for the code right here.
So that's definitely working out pretty well.
Next is the redirect to your eye.
Now obviously based on the error message we got this is part of what's going on wrong so let's just
take a pause over that one really quickly.
We'll talk about the other two properties first.
So here is our scope.
These are the two pieces of information that we're asking for.
We want to get access to the user's profile and their e-mail address.
And then finally we also have the client I.D. which identifies our application to Google's servers.
OK.
So the redirect you are I remember the redirect you are right here.
Well I shouldn't say remember because we haven't really specifically spoken about it just yet but if
you look at the your redirect your eye very closely you will see HTP localhost 5000 off Google Colback.
So the redirect you or I is the address that a user should be redirected to from Google after they give
permission to our application.
So remember after the user grants permission we had said that the user should be redirected to localhost
five thousand off Google callback and we had even set up that particular route inside of our Google
strategy.
So here's the Google strategy and here's that callback you are l where we had specifically said after
the user grants permission send them to this route right here.
So clearly that is being communicated correctly over to Google like here's the route.
Without a doubt.
But here's the problem here's what's going on.
I want you to imagine for a second that you and I were hackers right.
Like we are malicious users we are bad people and we want to somehow hijack someone's authentication
flow or they're all off low.
Maybe if we took this entire Big R L which clearly attempts to authenticate some user and tell the user
hey this these people over here like whoever owns this idea wants to get access to your user account.
Let's imagine for a second that you and I were malicious users and we replaced this client id right
here with some really official Client ID because remember the client id is public.
Everyone knows everyone else's client ID.
So maybe we like took Air B and B is Client ID from Google Earth and we put it in here and then we wanted
to somehow hijack users and think that they were authenticating with Air B and B but in fact we were
going to send them back to our servers and record all of their account information which is obviously
not a good thing.
Very malicious.
One possibility of how we could pull this off is to change the redirect to your eye and say instead
of sending the user back into I dont know.
You know Aramean BS fluorite here which might be like Air B and B dot com.
Maybe you and I would change this to our hacker server dot com slash off.
So now if we could get away with this we could somehow trick users into clicking this link the user
would be presented with some message that says oh it looks like air and B is trying to get access to
your profile.
The user would say oh yeah that's fantastic it's urban B I trust them.
But after these are granted permission Google would send the user back to our Hakkar server dot com
with a special code inside the your L and then our malicious server our hacker server could then make
that Falah request over to Google with the code and say hey give me some information about this user.
And so it's very easy to imagine how this entire old schema this entire Austine could be very easily
manipulated into giving or tricking really tricking users into giving their authentication or their
profile information to malicious actors or bad people.
So how is that actually all related to our application like what's actually going on here.
Well if we look at the actual error message right here it says redirect you are a mismatch.
In other words when we set up our flow and we said send the user back to auth slash Google slash callback.
We had not properly set up our account to say that that was a valid you or I to redirect that user to.
So Google internally tracks what valid you are eyes.
We can you or els or user can be redirected to so that malicious users or bad people can't just replace
the redirect to you or I'd right here and say oh yes send them over to this rental place instead.
Google is going to look at this redirect you or I that we are providing to them and verified ahead of
time and say OK does this person or does this redirect you or is this like an authorized target like
is it permissible for us to send the user back here.
We're going to check against our own records and if they're not allowed to go there then we're going
to throw this big error message.
So that's pretty much what's going on.
The purpose of this redirect you or I air that we're seen right here is entirely security related is
to make sure that users do not get accidently tricked into providing their profile information to that
people.
So how do we fix it.
Well it's pretty straightforward.
We get a link right here to update our authorized client redirect you or I sign it.
Copy that link.
I'm going to make a new tab.
I'm going to visit it directly.
And then the page that's going to pop up is probably going to look just a little bit familiar.
So we got sent back to the Google Developer Council specifically to the page where we had set up our
original client ID.
So on here is a list of all of our authorized redirect to our eyes.
We had entered a you or I.
You'll notice that it did not exactly match up with the route that we asked the user to be sent back
to.
So rather than saying localhost Kulin 5000 slash star We're going to say local host Conan 5000 slash
Auth. slash Google slash callback and then we'll hit save and make sure you get the dot dot dot on there.
OK.
So now whenever a user gets sent into our waterflow we are going to say to Google hey after they give
us permission kick them back to this exact address right here.
Google will say oh it looks like that is a permissible address or a permissible redirect you or I.
So that's totally fine.
We can safely send them back there and the user will be sent back to this address and then we will handle
the follow up request appropriately.
OK.
So this has been one crazy little piece of cloth.
Hopefully maybe this flow is starting to make a little bit more sense right now and you're starting
to get a little bit of a sense of some of the security considerations around a lot as well.
Now one thing I want to say is that if you attempt to test the flow again right now you might still
see the same error message.
That's because it takes a little bit of time for this new redirect your eye to actually kick in and
be registered on Google servers.
So we're going to take a pause right now.
We're going to pause and I recommend you maybe take like a five minute pause you know go grab a drink
or something.
And by the time you get back this new redirect you or I should be accessible on Google servers or should
be actually active because again it takes some small amount of time for it's actually kind of kick in.
So it will take a break and when we come back we will test our water flow again.
So we'll see you in just a second.