We just took a look at authentication solution number one where we had a reliance or dependency on some
central service.
We took a look at a slight variation of that where we had some central gateway that would essentially
block on authenticator requests and we also had another one this was option number two where we said
that we're going to teach each service how to authenticate an incoming request.
Now I really made it sound as though option number two was pretty great because we don't have any dependency
on any outside service.
So everything else inside our application could crash and come down tumbling burn to the ground absolutely.
But our order service is still going to work correctly.
That sounds great but yeah there's definitely some downsides.
So let's understand what these downsides are.
OK.
So for just a minute I want you to understand or imagine the following sequence of actions.
Let's imagine that some user comes to our application to sign it.
We are going to call them user ABC so this user ABC comes to our application to sign and through our
authentication service which at all times is what we intended the authentication service at all times
will be in charge of signing up and signing in that sign up sign and process is not related to this
discussion of where we are going to put this logic to decide if a user's authenticated user ABC makes
a request to sign in.
They supply some email and password.
We have some sign and logic where we're gonna check that email and password against our stored ones
including that whole hashing process and all that whatnots.
And in this scenario we'll imagine at this user ABC it supplied the correct email and password.
So we say hey correct e-mail correct password Fantastic.
Here is a token to identify you included on all follow up requests.
And this is what is going to identify you to the different services inside of our application.
So we will send back a Jason web token a cookie whatever it is who knows we send back something that
this user can use to authenticate themselves with our different services get that step one.
Now let's imagine that we are following fundamental option number two.
So that means that user ABC can take this on web token cookie or whatever and they can use it to do
with just about anything inside of our application that is tied to authentication so they can use that
thing that we just gave them to purchase a ticket or do whatever else.
And very critically when they try to purchase a ticket we are not going to go back out and communicate
to that authentication service.
We are just taking a look at that single Jason web token that this user has 100 percent control over.
So we're just gonna take that thing and say all right is this thing valid.
Yeah it is.
OK.
You are signed and fantastic.
Yes.
So now we set the scene.
Let's now imagine what might happen after user ABC if that identifying token so let's imagine that it
turns out that user ABC is actually not the nicest person in the world maybe it turns out that this
is some malicious user maybe it's some employee at our company who just got fired for doing something
really nasty at any rate let's imagine that we have some administrator a user inside our application
who urgently needs to ban user ABC.
We need to make sure that user ABC can not access any of our services anymore because we are very much
certain that this is a bad person who's going to do some nasty stuff to our application so we're going
to imagine that admin user is going to submit a request once again to our authentication service because
hey it makes sense to handle handled some stuff like any user inside of an authentication service.
So they're going to submit that request and they're gonna specify the user to ban so we'll send that
off to maybe some new request handler in cyber authentication service related to user management inside
there.
We're gonna have some code to say OK we want to ban all user ABC.
OK.
Got it.
Well fantastic.
Let's go and update the database to reflect that this user is now banned.
And so even though we don't have any property like this tied to our user model we can imagine that maybe
we would add in a property to our user model as restoring inside of Mongo DB.
But something like has access or is banned or something like that.
Some flag to say whether or not this user is banned.
So in this case because we are banning a user maybe you would we would flip has access over to false
so this user no longer should have access to our application.
Now in theory part of our app one of the services inside of our app says that user ABC is banned but
what is really going on.
What happens if a user user ABC now makes a follow up request.
Well let's imagine the flow.
What would really go on here.
Let's say that after being banned user ABC now makes a request to purchase a ticket once again.
And at this point we've determined that user ABC is a bad person.
And who knows what they're doing.
But we do not want them to get access to anything inside of our app.
So we would definitely without a doubt want to reject this request.
But remember user ABC still has that original Jason web token they still got that cookie.
It is 100 percent in their control.
We cannot somehow reach directly into their computer and tell them hey you need to delete this thing
right away user ABC has 100 percent control of that token that proves that they are authenticated.
So what would happen when they now make a request to purchase this ticket.
Well they would send that request in.
It would be going to our order service our order service would have this ticket purchase logic.
We would check to see if this person is logged in.
So we would take that Jason web token which is still 100 percent valid because we have not been able
to tinker with it at all because it's in control of user ABC.
So we would expect that thing and decide if the user is authenticated and we would say yeah they are.
It's a valid token.
No problem with it whatsoever because at no point in time did we go over to our service and check to
see if this user should have access.
We're 100 percent decoupled from this thing.
There's no coupling whatsoever.
We don't care what the art service has to say.
So even though the auto service is 100 percent certain that this user should not have access to our
application at no point using option number two because remember that's what we're discussing here.
At no point with option number two do we ever go over to that service to figure out whether or not this
person is still authenticated so that is the core issue with this approach even though we get this fantastic
separation of services.
We don't have any dependencies.
There are still going to be scenarios where we tried to update data in one location tied to a user status
but all the other services are not going to hear about that update.
They don't know.
They don't have any logic to be told hey this user is now banned or something like that because there's
no direct connection between the two but that is the fundamental problem with option number two.
So hopefully now you can start to see why all this authentication stuff is a really nasty thing.
It is an unsolved problem.
There's no single solution out there that is just the right way to do it.
We have to pick the best way out of all the options we have available and we can also try to figure
out some clever ways to work around some of these restrictions.
OK so now that we see that handle this stuff is way more complicated than you might guess.
At first glance let's take a pause right here.
We're gonna come back the next video and I'm going to tell you about the solution that we are going
to take even though it still has some downsides so quick pause continue in just a minute.