As I mentioned just a moment ago we are going fundamental option here two in this video I need to tell
you one way in which we could get around this really big security issue.
This video is optional.
So if you do not want to hear this explanation no problem.
Just move on to the next video.
Otherwise stick around and let's get to it now I want you to understand right away that we are not going
to implement the strategy that I'm going to suggest here.
And the reason for that is that it is a tremendous amount of extra work.
And we already have a lot on our plate as it stands right now.
So what I'm going to show you is a very viable strategy without a doubt.
But we are not going to go through it just for the sake of time.
OK.
So here's the general idea.
We're still going to have user ABC attempt to sign in or something like that with some centralized authentication
service.
We're going to do the check on e-mail password and eventually hand back a token.
But here is the big change.
Here's the key.
When we sent back that Jason a web token or that cookie or whatever it is we're going to somehow make
sure that that thing is only viable for the next 15 minutes.
How do we do that.
Well there are mechanisms around Jason web tokens in particular for making sure that it's really clear
that this token is only viable for some set period of time so we can absolutely have some authentication
mechanism that is going to expire after 15 minutes that 15 minutes that I'm listening out here is totally
arbitrary.
It could be 15 seconds.
It could be 15 days for this example.
I'm just going to say that we're gonna have some mechanism for authentication that only works for 15
minutes so that mind let's now imagine what would happen if user ABC attempted to make a request to
purchase some ticket through our order service.
So again here's user ABC.
They're going to make a request to purchase a ticket and they are going to supply a Jason web token
cookie whatever that is 30 minutes old.
So in this scenario we're going to say that they have some expired mechanism.
So when they make this request we're then going to ask if this person is logged in because we are following
option number two we are going to rely upon our order service to take a look at that.
Jason web token and decide if the user is authenticated so we're going to run some logic to look at
that token and critically inside this logic we're going to add something to say if that Jason web token
is older than 30 minutes then this person is not authenticated if they have an expired token.
There are two ways that we can deal with it very easily.
We can either have our order service or this logic running inside of your attempt to reach out to the
authentication service and get a new refreshed token so we can reach out directly with a synchronous
request of the authentication service get a refresh token and then when we respond to the overall request
we could include the new refresh token and send it back to user ABC.
That is one possible approach and would allow us to refresh the token all in one request while still
achieving the overall goal.
Now the nice thing about this approach is that it requires us if this token is expired to reach out
to the authentication service and so that would be a time for the authentication service to chime in
and say hey this person is banned.
Don't allow them access or something like that.
The other strategy we can take here if we do not want to have the synchronous communication we could
say that if the Jason web token is older than 30 minutes then we are just going to reject the overall
request.
So we could return early and send back in air and tell them hey before you make a request to us you
need to go and refresh your token.
And so rather than doing these synchronous requests ourselves we can tell our client that they have
to go over to the authentication service and refresh that token on their own.
And then once that was done once they got the updated token that would now be say 10 seconds old now
they can make the follow up requests or repeat the same request again to purchase a ticket with the
brand new refresh token so this definitely solves kind of the issue.
We still have a window here a window of 15 minutes where we could potentially ban a user and then they
could continue making requests in the window of those 15 minutes.
And so this is where it really starts to get into your personal implementation into your application
into the requirements of what you are building.
You might be building an app where that 15 minute window is tolerable.
You might need to say oh yeah 50 minutes no problem.
You could even take it down to five minutes or a minute and there might be some window of time that
you would be happy with and saying yeah if the person gets banned they can still make requests in the
span of time.
I don't care.
But maybe you are working on some even more secure app where you say no there cannot be any period of
time where a user gets banned and then can make follow up requests and still be authenticated.
If that is the case don't worry I still got a solution for you.
So if you really need to tighten that window and to make sure that as soon as the user gets marked as
banned they are effectively banned as quickly as possible.
Here's what we would do get so in this approach we would imagine that a administration user would make
a request to ban user ABC so very much what we discussed before inside of our art service.
We would have some user management logic and we would reach out to our database and Mark user ABC as
not having access anymore.
So effectively they are banned as far as the authentication service is concerned.
But we want to reflect this change immediately with all of our services as well.
And we would probably want to do so using the same communication patterns as we've already seen.
In other words using events as opposed to synchronous requests.
So here's how we would handle that right after we update the database.
We would then also emit a user band event or something very similar to it would be some kind of event
that says hey all service is out there anyone who is listening do not allow this user to access the
application so we would send that out to our event bus and that event might look like this right here
would be sent off to all of our different services then inside of each of our services we could take
that information out of that event.
So something that says do not allow access to user ABC and we could persisted in some very short lived
cash or some kind of short lived data store something to say hey here's all the users who should be
banned in who we should revoke access to.
Now the reason I'm saying short lived in memory cashier is that remember we don't really want to be
storing a list for all eternity of users who are banned users might get banned or unbanned all the time.
Who knows.
The reason I'm saying short lived right here is that we can just persist this data for 15 minutes the
same duration of time as the lifecycle or the lifetime of these just on web tokens because after 15
minutes we don't need the store anymore after 15 minutes our service is going to immediately know or
immediately see that incoming Jason Webb tokens are expired and so immediately they will eject reject
the request within those 15 minutes we can temporarily store this information that this user should
be banned.
So the reason I'm saying short lived in memory cashier is that we do not need to persist this for all
time.
We only need to persist this list of banned users in each individual service for an amount of time equal
to the lifetime of our authentication mechanism so the upside to this approach is that we can immediately
ban a user from all of our different services.
The downside is that well we have to have some implementation in each service we're listening to this
event storing this list of users and then comparing whenever we run some authentication logic.
So once again not that big a deal to add that code into each service because we could implement that
in some shared library but again it is just extra complexity that we need to be aware of.
All right.
So that's it.
That is how we could still implement option or two and not have any window whatsoever inside there.
Now again we're not going to implement this stuff because really far out there and I would really prefer
in this course to show you a lot more actual application level business logic kind of stuff than go
over more and more authentication stuff.
But I did want you to understand that yes we can go with option or two and still have a very secure
approach gets and they've gone over this pause and we will start to implement option or two in the next
video.