1
00:00:01,820 --> 00:00:05,780
As I mentioned just a moment ago we are going fundamental option here two in this video I need to tell

2
00:00:05,780 --> 00:00:09,350
you one way in which we could get around this really big security issue.

3
00:00:09,350 --> 00:00:10,570
This video is optional.

4
00:00:10,580 --> 00:00:13,100
So if you do not want to hear this explanation no problem.

5
00:00:13,100 --> 00:00:14,410
Just move on to the next video.

6
00:00:14,780 --> 00:00:19,340
Otherwise stick around and let's get to it now I want you to understand right away that we are not going

7
00:00:19,340 --> 00:00:21,550
to implement the strategy that I'm going to suggest here.

8
00:00:21,560 --> 00:00:25,190
And the reason for that is that it is a tremendous amount of extra work.

9
00:00:25,370 --> 00:00:28,490
And we already have a lot on our plate as it stands right now.

10
00:00:28,880 --> 00:00:33,120
So what I'm going to show you is a very viable strategy without a doubt.

11
00:00:33,290 --> 00:00:35,810
But we are not going to go through it just for the sake of time.

12
00:00:36,190 --> 00:00:36,550
OK.

13
00:00:36,620 --> 00:00:38,220
So here's the general idea.

14
00:00:38,510 --> 00:00:45,300
We're still going to have user ABC attempt to sign in or something like that with some centralized authentication

15
00:00:45,300 --> 00:00:46,150
service.

16
00:00:46,150 --> 00:00:49,650
We're going to do the check on e-mail password and eventually hand back a token.

17
00:00:49,680 --> 00:00:51,660
But here is the big change.

18
00:00:51,660 --> 00:00:52,500
Here's the key.

19
00:00:53,100 --> 00:00:58,320
When we sent back that Jason a web token or that cookie or whatever it is we're going to somehow make

20
00:00:58,320 --> 00:01:03,230
sure that that thing is only viable for the next 15 minutes.

21
00:01:03,240 --> 00:01:04,380
How do we do that.

22
00:01:04,380 --> 00:01:09,690
Well there are mechanisms around Jason web tokens in particular for making sure that it's really clear

23
00:01:10,170 --> 00:01:16,890
that this token is only viable for some set period of time so we can absolutely have some authentication

24
00:01:16,890 --> 00:01:23,160
mechanism that is going to expire after 15 minutes that 15 minutes that I'm listening out here is totally

25
00:01:23,160 --> 00:01:24,010
arbitrary.

26
00:01:24,030 --> 00:01:25,290
It could be 15 seconds.

27
00:01:25,290 --> 00:01:27,560
It could be 15 days for this example.

28
00:01:27,570 --> 00:01:32,250
I'm just going to say that we're gonna have some mechanism for authentication that only works for 15

29
00:01:32,310 --> 00:01:39,560
minutes so that mind let's now imagine what would happen if user ABC attempted to make a request to

30
00:01:39,560 --> 00:01:42,320
purchase some ticket through our order service.

31
00:01:42,320 --> 00:01:44,210
So again here's user ABC.

32
00:01:44,210 --> 00:01:49,820
They're going to make a request to purchase a ticket and they are going to supply a Jason web token

33
00:01:49,820 --> 00:01:52,580
cookie whatever that is 30 minutes old.

34
00:01:52,580 --> 00:01:56,930
So in this scenario we're going to say that they have some expired mechanism.

35
00:01:56,930 --> 00:02:02,150
So when they make this request we're then going to ask if this person is logged in because we are following

36
00:02:02,180 --> 00:02:06,470
option number two we are going to rely upon our order service to take a look at that.

37
00:02:06,470 --> 00:02:13,130
Jason web token and decide if the user is authenticated so we're going to run some logic to look at

38
00:02:13,130 --> 00:02:20,120
that token and critically inside this logic we're going to add something to say if that Jason web token

39
00:02:20,120 --> 00:02:27,230
is older than 30 minutes then this person is not authenticated if they have an expired token.

40
00:02:27,260 --> 00:02:30,440
There are two ways that we can deal with it very easily.

41
00:02:30,440 --> 00:02:35,270
We can either have our order service or this logic running inside of your attempt to reach out to the

42
00:02:35,270 --> 00:02:42,350
authentication service and get a new refreshed token so we can reach out directly with a synchronous

43
00:02:42,350 --> 00:02:48,200
request of the authentication service get a refresh token and then when we respond to the overall request

44
00:02:48,500 --> 00:02:54,150
we could include the new refresh token and send it back to user ABC.

45
00:02:54,170 --> 00:02:59,360
That is one possible approach and would allow us to refresh the token all in one request while still

46
00:02:59,360 --> 00:03:01,700
achieving the overall goal.

47
00:03:01,710 --> 00:03:06,840
Now the nice thing about this approach is that it requires us if this token is expired to reach out

48
00:03:06,840 --> 00:03:11,550
to the authentication service and so that would be a time for the authentication service to chime in

49
00:03:11,580 --> 00:03:14,330
and say hey this person is banned.

50
00:03:14,340 --> 00:03:17,840
Don't allow them access or something like that.

51
00:03:17,870 --> 00:03:21,650
The other strategy we can take here if we do not want to have the synchronous communication we could

52
00:03:21,650 --> 00:03:26,420
say that if the Jason web token is older than 30 minutes then we are just going to reject the overall

53
00:03:26,420 --> 00:03:27,460
request.

54
00:03:27,470 --> 00:03:32,870
So we could return early and send back in air and tell them hey before you make a request to us you

55
00:03:32,870 --> 00:03:34,970
need to go and refresh your token.

56
00:03:34,970 --> 00:03:39,650
And so rather than doing these synchronous requests ourselves we can tell our client that they have

57
00:03:39,650 --> 00:03:44,330
to go over to the authentication service and refresh that token on their own.

58
00:03:44,330 --> 00:03:53,990
And then once that was done once they got the updated token that would now be say 10 seconds old now

59
00:03:53,990 --> 00:03:58,640
they can make the follow up requests or repeat the same request again to purchase a ticket with the

60
00:03:58,700 --> 00:04:06,070
brand new refresh token so this definitely solves kind of the issue.

61
00:04:06,160 --> 00:04:11,920
We still have a window here a window of 15 minutes where we could potentially ban a user and then they

62
00:04:11,920 --> 00:04:15,860
could continue making requests in the window of those 15 minutes.

63
00:04:15,910 --> 00:04:20,800
And so this is where it really starts to get into your personal implementation into your application

64
00:04:20,800 --> 00:04:23,200
into the requirements of what you are building.

65
00:04:23,200 --> 00:04:27,010
You might be building an app where that 15 minute window is tolerable.

66
00:04:27,100 --> 00:04:29,440
You might need to say oh yeah 50 minutes no problem.

67
00:04:29,440 --> 00:04:35,560
You could even take it down to five minutes or a minute and there might be some window of time that

68
00:04:35,560 --> 00:04:40,300
you would be happy with and saying yeah if the person gets banned they can still make requests in the

69
00:04:40,300 --> 00:04:41,020
span of time.

70
00:04:41,020 --> 00:04:41,760
I don't care.

71
00:04:42,520 --> 00:04:47,710
But maybe you are working on some even more secure app where you say no there cannot be any period of

72
00:04:47,710 --> 00:04:53,470
time where a user gets banned and then can make follow up requests and still be authenticated.

73
00:04:53,620 --> 00:04:57,230
If that is the case don't worry I still got a solution for you.

74
00:04:57,310 --> 00:05:01,990
So if you really need to tighten that window and to make sure that as soon as the user gets marked as

75
00:05:01,990 --> 00:05:05,320
banned they are effectively banned as quickly as possible.

76
00:05:05,320 --> 00:05:12,090
Here's what we would do get so in this approach we would imagine that a administration user would make

77
00:05:12,090 --> 00:05:19,040
a request to ban user ABC so very much what we discussed before inside of our art service.

78
00:05:19,050 --> 00:05:25,110
We would have some user management logic and we would reach out to our database and Mark user ABC as

79
00:05:25,110 --> 00:05:26,550
not having access anymore.

80
00:05:26,550 --> 00:05:30,810
So effectively they are banned as far as the authentication service is concerned.

81
00:05:30,810 --> 00:05:35,010
But we want to reflect this change immediately with all of our services as well.

82
00:05:35,010 --> 00:05:39,200
And we would probably want to do so using the same communication patterns as we've already seen.

83
00:05:39,200 --> 00:05:43,470
In other words using events as opposed to synchronous requests.

84
00:05:43,470 --> 00:05:47,420
So here's how we would handle that right after we update the database.

85
00:05:47,460 --> 00:05:52,500
We would then also emit a user band event or something very similar to it would be some kind of event

86
00:05:52,500 --> 00:05:57,390
that says hey all service is out there anyone who is listening do not allow this user to access the

87
00:05:57,390 --> 00:06:02,770
application so we would send that out to our event bus and that event might look like this right here

88
00:06:02,830 --> 00:06:10,700
would be sent off to all of our different services then inside of each of our services we could take

89
00:06:10,700 --> 00:06:12,610
that information out of that event.

90
00:06:12,740 --> 00:06:18,920
So something that says do not allow access to user ABC and we could persisted in some very short lived

91
00:06:18,980 --> 00:06:25,280
cash or some kind of short lived data store something to say hey here's all the users who should be

92
00:06:25,280 --> 00:06:28,090
banned in who we should revoke access to.

93
00:06:28,130 --> 00:06:33,170
Now the reason I'm saying short lived in memory cashier is that remember we don't really want to be

94
00:06:33,170 --> 00:06:40,070
storing a list for all eternity of users who are banned users might get banned or unbanned all the time.

95
00:06:40,070 --> 00:06:41,010
Who knows.

96
00:06:41,210 --> 00:06:46,610
The reason I'm saying short lived right here is that we can just persist this data for 15 minutes the

97
00:06:46,610 --> 00:06:53,810
same duration of time as the lifecycle or the lifetime of these just on web tokens because after 15

98
00:06:53,810 --> 00:07:00,950
minutes we don't need the store anymore after 15 minutes our service is going to immediately know or

99
00:07:00,950 --> 00:07:06,770
immediately see that incoming Jason Webb tokens are expired and so immediately they will eject reject

100
00:07:06,770 --> 00:07:12,770
the request within those 15 minutes we can temporarily store this information that this user should

101
00:07:12,770 --> 00:07:13,840
be banned.

102
00:07:13,840 --> 00:07:17,720
So the reason I'm saying short lived in memory cashier is that we do not need to persist this for all

103
00:07:17,720 --> 00:07:18,350
time.

104
00:07:18,350 --> 00:07:23,930
We only need to persist this list of banned users in each individual service for an amount of time equal

105
00:07:23,930 --> 00:07:31,970
to the lifetime of our authentication mechanism so the upside to this approach is that we can immediately

106
00:07:31,970 --> 00:07:34,640
ban a user from all of our different services.

107
00:07:34,640 --> 00:07:39,470
The downside is that well we have to have some implementation in each service we're listening to this

108
00:07:39,470 --> 00:07:45,410
event storing this list of users and then comparing whenever we run some authentication logic.

109
00:07:45,410 --> 00:07:49,970
So once again not that big a deal to add that code into each service because we could implement that

110
00:07:49,970 --> 00:07:54,050
in some shared library but again it is just extra complexity that we need to be aware of.

111
00:07:55,110 --> 00:07:55,370
All right.

112
00:07:55,470 --> 00:07:56,160
So that's it.

113
00:07:56,160 --> 00:08:02,360
That is how we could still implement option or two and not have any window whatsoever inside there.

114
00:08:02,370 --> 00:08:07,380
Now again we're not going to implement this stuff because really far out there and I would really prefer

115
00:08:07,380 --> 00:08:12,810
in this course to show you a lot more actual application level business logic kind of stuff than go

116
00:08:12,810 --> 00:08:15,450
over more and more authentication stuff.

117
00:08:15,450 --> 00:08:19,830
But I did want you to understand that yes we can go with option or two and still have a very secure

118
00:08:19,860 --> 00:08:25,260
approach gets and they've gone over this pause and we will start to implement option or two in the next

119
00:08:25,260 --> 00:08:25,590
video.