We are finally to the last step of our sign up process so we are now considering a user to be signed
in.
And that means we need to somehow generate a cookie or Jason web token.
Something like that and send it back over to the user and the user should then use that token.
That cookie whatever it is to attempt to access other services inside of application and prove that
they are actually signed in now handling authentication handling the process of making sure that someone
is sending us request who is logged into our application is deceptively challenging in micros services
are going to first start off with a little disclaimer here handling it user authentication.
So in other words giving a user a cookie a Jason web token or something similar and allowing them to
access other services inside of our app is a challenging problem that is not really solved.
In other words there is not really a perfect solution to handling this stuff.
There is not some strategy where we just say oh yeah I use a cookie or use adjacent web token.
And tonight everything works that doesn't exist.
So instead with micros services and in the context of this course I'm going to try to outline a couple
of different possible approaches in handling authentication approaches and how we can say hey user here's
a cookie or here's a token of sorts.
Give this to us in the future and how we can decide whether or not a user truly is authenticated.
We're going to take a look at these different solutions and I'm going to eventually show you one that
is going to work but it is definitely by no means perfect in nature.
OK so enough this disclaimer.
Let's get to it.
So I want you to imagine for a second that eventually inside of our application which remember is all
about selling tickets and whatnot that we will eventually have some kind of service called the order
service and inside this order service the goal is to allow users to purchase a ticket so we can imagine
that inside that service we'll probably have something like ticket purchasing logic probably a request
handler something like that.
And we could definitely imagine that at some point time someone's going to send a request to the service
with the goal of purchasing a ticket maybe in the body of the ticket they'll have the ticket I.D. or
be the body to request the ticket I.D. or something like that.
And of course along with this request a user is going to have to prove that they are authenticated with
our application.
So along with the request they're going to have to include some Jason web token some cookie or something
similar something to say I am signed in then inside of our request handler we are going to have to have
some logic to say is this person actually signed in.
Did they give us a valid Jason web token.
Did they give us some cookie with some authentication information side of it and we need to decide whether
or not this person who's sending us this request is actually signed into our app so this whole discussion
we are about to have and this whole disclaimer right here about user authentication really comes down
to how we answer this question how do we decide whether or not someone is logged in in a micro services
app.
This is way more challenging and deceptive than you would think.
So again I'm going to show you two big approaches here is approach number one now on this first approach
I've labeled it fundamental.
Option number one the reason I'm putting the word fundamental in here is that I'm going to show you
two general approaches to general strategies but there are very much variations of each of these at
the end of the day though all the different strategies out there really come down to two very fundamental
principles.
That's why I'm calling this fundamental option number one.
Again you're going to find variations of this but it really comes down to this idea.
The idea is that we are going to allow individual services to rely on some centralized authentication
service to decide whether or not a user is logged in so let's again imagine that same scenario where
someone's make your request to purchase a ticket it goes into our order service.
We then need to ask and decide whether or not this person is logged in.
So to answer that question with fundamental option number one we might take that Jace on a Web token
or that cookie or whatever else and send it in some synchronous request off to our authentication service
and the authentication service might have some logic to take a look at that.
Jason a web token that cookie or whatever else and aside if this user is authenticated and so it would
be up to the authentication service to send a response back over now remember I'm using the term here
sync request not in the world of javascript but in the world of micros services in the world micros
services sync request refers to a direct request from one service to another one that does not make
use of events or event buses or anything like that so the downside of fundamental option one really
shares all the same downsides as synchronous communication in general.
If we put together this kind of solution right here.
Think about what would happen if the authentication service just mysteriously went down one day.
If that thing crashed or just disappeared all of a sudden no one no service inside of our entire application
can decide if a person is logged in and that means that any request that requires us to decide if a
person is authenticated is automatically going to fail.
So by using this fundamental option number one.
Well we are going to be in a world of hurt if anything goes wrong with our authentication service.
That's a very clear downside to fundamental option number one.
All right let's move on.
We're going to show you some other pros and cons as we go on.
But for right now let's just go to the next option.
Now this is option one point one.
So it's really the same as what we're just looking at just about identical in nature but we just kind
of move some stuff around at the end of the day fundamental option number one is still very very close
to option number one because we are still relying upon the service 100 percent of the time.
The only reason I'm showing you one point one right here is to help you understand that yes there are
variations in these strategies.
So with this strategy we would say that any request coming into our application would need to go through
some central gateway of sorts that would authenticate the incoming request.
So whenever a user makes a request to purchase a ticket rather than going directly to the order service
we would instead have it flow into some authentication gateway or some authentication service of sorts
that would inspect that incoming request and decide if the user is authenticated if they are.
We would then send the request along to the intended destination.
Otherwise we would just reject it right away.
This still shares a lot of the pros and cons of this option number one right here because we would still
have a 100 percent reliance on the authentication service in both cases if this thing ever goes down
or if this thing ever goes down all of a sudden we can not make a single request that requires any kind
of authentication.
Again I'm only showing you this option one point one to say yeah there's variations on these things
but they are at the other day very similar in nature.
Now let's move on to the next option.
What's the really option too.
What's different approach we could take here.
Well here's option number two with fundamental option number two.
We are going to teach each individual service how to decide whether or not a user is authenticated.
So for example whenever someone makes a request to purchase a ticket to our order service and inside
there we need to decide whether or not this person is logged in.
Then we will teach this service how to take a look at the request.
Jason web token cookie whatever we are using and decide whether or not the user is authenticated.
So in this scenario we have no dependency on outside services no dependency on a gateway.
Some other service or anything like that.
Everything is wrapped up inside of one single service.
And if a user ever makes requests to this thing we will immediately and instantly know whether or not
this user is logged in.
And so the upsides this approach are very clear.
We do not have any outside dependency as we did previously on this OTT service.
If you give us a token and it's valid Hey you must be logged in.
We're good to go and we will process your request so it immediately might seem like fundamental option
number two is way better because we don't have any outside dependency.
There is a very clear and immediate downside that you could probably imagine and that is that we're
going to end up duplicating this authentication logic between all of our different services.
I want you know right now that's not a big deal.
We could easily move this authentication logic into a shared library that's used among all of our services.
And so we can really just have very few implementations that get shared all over the place.
So not really concerned about duplicating any of that logic but there are some much more larger fundamental
very critical downsides of fundamental option number two.
You really need to understand these because these the issues around fundamental option number two is
where we are going to start to see that micros services communicating with each other is really really
challenging.
Now this video is running a little bit long.
Let's take a pause right here.
We're gonna come back the next video and I wanted to show you the absolute very critical to understand
downsides of option number two even though it looks like it's really great.
As it stands right now does continue in just a minute.