1
00:00:00,980 --> 00:00:06,320
We just took a look at authentication solution number one where we had a reliance or dependency on some

2
00:00:06,320 --> 00:00:07,600
central service.

3
00:00:07,700 --> 00:00:11,900
We took a look at a slight variation of that where we had some central gateway that would essentially

4
00:00:11,900 --> 00:00:17,450
block on authenticator requests and we also had another one this was option number two where we said

5
00:00:17,450 --> 00:00:21,170
that we're going to teach each service how to authenticate an incoming request.

6
00:00:21,200 --> 00:00:26,030
Now I really made it sound as though option number two was pretty great because we don't have any dependency

7
00:00:26,060 --> 00:00:27,410
on any outside service.

8
00:00:27,800 --> 00:00:33,810
So everything else inside our application could crash and come down tumbling burn to the ground absolutely.

9
00:00:33,830 --> 00:00:36,780
But our order service is still going to work correctly.

10
00:00:36,800 --> 00:00:39,370
That sounds great but yeah there's definitely some downsides.

11
00:00:39,380 --> 00:00:41,900
So let's understand what these downsides are.

12
00:00:41,920 --> 00:00:42,230
OK.

13
00:00:42,290 --> 00:00:47,090
So for just a minute I want you to understand or imagine the following sequence of actions.

14
00:00:47,660 --> 00:00:51,220
Let's imagine that some user comes to our application to sign it.

15
00:00:51,350 --> 00:00:57,740
We are going to call them user ABC so this user ABC comes to our application to sign and through our

16
00:00:57,770 --> 00:01:02,960
authentication service which at all times is what we intended the authentication service at all times

17
00:01:02,960 --> 00:01:08,240
will be in charge of signing up and signing in that sign up sign and process is not related to this

18
00:01:08,240 --> 00:01:14,810
discussion of where we are going to put this logic to decide if a user's authenticated user ABC makes

19
00:01:14,810 --> 00:01:15,760
a request to sign in.

20
00:01:15,830 --> 00:01:18,100
They supply some email and password.

21
00:01:18,170 --> 00:01:22,190
We have some sign and logic where we're gonna check that email and password against our stored ones

22
00:01:22,760 --> 00:01:25,720
including that whole hashing process and all that whatnots.

23
00:01:25,790 --> 00:01:30,520
And in this scenario we'll imagine at this user ABC it supplied the correct email and password.

24
00:01:30,620 --> 00:01:33,870
So we say hey correct e-mail correct password Fantastic.

25
00:01:34,040 --> 00:01:38,660
Here is a token to identify you included on all follow up requests.

26
00:01:38,660 --> 00:01:44,240
And this is what is going to identify you to the different services inside of our application.

27
00:01:44,240 --> 00:01:50,840
So we will send back a Jason web token a cookie whatever it is who knows we send back something that

28
00:01:50,840 --> 00:01:56,880
this user can use to authenticate themselves with our different services get that step one.

29
00:01:56,900 --> 00:02:02,050
Now let's imagine that we are following fundamental option number two.

30
00:02:02,060 --> 00:02:09,470
So that means that user ABC can take this on web token cookie or whatever and they can use it to do

31
00:02:09,470 --> 00:02:13,700
with just about anything inside of our application that is tied to authentication so they can use that

32
00:02:13,700 --> 00:02:18,690
thing that we just gave them to purchase a ticket or do whatever else.

33
00:02:18,800 --> 00:02:23,840
And very critically when they try to purchase a ticket we are not going to go back out and communicate

34
00:02:23,840 --> 00:02:25,780
to that authentication service.

35
00:02:25,850 --> 00:02:32,360
We are just taking a look at that single Jason web token that this user has 100 percent control over.

36
00:02:32,400 --> 00:02:35,480
So we're just gonna take that thing and say all right is this thing valid.

37
00:02:35,480 --> 00:02:36,070
Yeah it is.

38
00:02:36,080 --> 00:02:36,280
OK.

39
00:02:36,290 --> 00:02:38,410
You are signed and fantastic.

40
00:02:38,410 --> 00:02:38,510
Yes.

41
00:02:38,540 --> 00:02:39,950
So now we set the scene.

42
00:02:40,010 --> 00:02:48,730
Let's now imagine what might happen after user ABC if that identifying token so let's imagine that it

43
00:02:48,730 --> 00:02:54,340
turns out that user ABC is actually not the nicest person in the world maybe it turns out that this

44
00:02:54,340 --> 00:02:59,710
is some malicious user maybe it's some employee at our company who just got fired for doing something

45
00:02:59,710 --> 00:03:06,130
really nasty at any rate let's imagine that we have some administrator a user inside our application

46
00:03:06,460 --> 00:03:10,660
who urgently needs to ban user ABC.

47
00:03:10,660 --> 00:03:16,810
We need to make sure that user ABC can not access any of our services anymore because we are very much

48
00:03:16,810 --> 00:03:22,320
certain that this is a bad person who's going to do some nasty stuff to our application so we're going

49
00:03:22,320 --> 00:03:27,440
to imagine that admin user is going to submit a request once again to our authentication service because

50
00:03:27,710 --> 00:03:33,390
hey it makes sense to handle handled some stuff like any user inside of an authentication service.

51
00:03:33,570 --> 00:03:38,880
So they're going to submit that request and they're gonna specify the user to ban so we'll send that

52
00:03:38,880 --> 00:03:44,170
off to maybe some new request handler in cyber authentication service related to user management inside

53
00:03:44,180 --> 00:03:44,600
there.

54
00:03:44,760 --> 00:03:48,410
We're gonna have some code to say OK we want to ban all user ABC.

55
00:03:48,440 --> 00:03:48,660
OK.

56
00:03:48,680 --> 00:03:49,490
Got it.

57
00:03:49,500 --> 00:03:50,420
Well fantastic.

58
00:03:50,430 --> 00:03:55,140
Let's go and update the database to reflect that this user is now banned.

59
00:03:55,230 --> 00:03:59,550
And so even though we don't have any property like this tied to our user model we can imagine that maybe

60
00:03:59,550 --> 00:04:04,070
we would add in a property to our user model as restoring inside of Mongo DB.

61
00:04:04,240 --> 00:04:08,180
But something like has access or is banned or something like that.

62
00:04:08,370 --> 00:04:12,200
Some flag to say whether or not this user is banned.

63
00:04:12,220 --> 00:04:17,880
So in this case because we are banning a user maybe you would we would flip has access over to false

64
00:04:18,870 --> 00:04:22,880
so this user no longer should have access to our application.

65
00:04:23,080 --> 00:04:30,860
Now in theory part of our app one of the services inside of our app says that user ABC is banned but

66
00:04:30,860 --> 00:04:32,380
what is really going on.

67
00:04:32,390 --> 00:04:37,350
What happens if a user user ABC now makes a follow up request.

68
00:04:37,350 --> 00:04:38,780
Well let's imagine the flow.

69
00:04:38,780 --> 00:04:41,580
What would really go on here.

70
00:04:41,630 --> 00:04:48,620
Let's say that after being banned user ABC now makes a request to purchase a ticket once again.

71
00:04:48,620 --> 00:04:52,310
And at this point we've determined that user ABC is a bad person.

72
00:04:52,450 --> 00:04:53,650
And who knows what they're doing.

73
00:04:53,660 --> 00:04:57,580
But we do not want them to get access to anything inside of our app.

74
00:04:57,650 --> 00:05:01,360
So we would definitely without a doubt want to reject this request.

75
00:05:01,520 --> 00:05:06,620
But remember user ABC still has that original Jason web token they still got that cookie.

76
00:05:06,620 --> 00:05:09,230
It is 100 percent in their control.

77
00:05:09,230 --> 00:05:13,490
We cannot somehow reach directly into their computer and tell them hey you need to delete this thing

78
00:05:13,490 --> 00:05:20,240
right away user ABC has 100 percent control of that token that proves that they are authenticated.

79
00:05:20,260 --> 00:05:24,120
So what would happen when they now make a request to purchase this ticket.

80
00:05:24,130 --> 00:05:26,930
Well they would send that request in.

81
00:05:27,130 --> 00:05:31,840
It would be going to our order service our order service would have this ticket purchase logic.

82
00:05:31,840 --> 00:05:33,780
We would check to see if this person is logged in.

83
00:05:33,910 --> 00:05:38,140
So we would take that Jason web token which is still 100 percent valid because we have not been able

84
00:05:38,140 --> 00:05:42,220
to tinker with it at all because it's in control of user ABC.

85
00:05:42,220 --> 00:05:47,770
So we would expect that thing and decide if the user is authenticated and we would say yeah they are.

86
00:05:47,890 --> 00:05:48,870
It's a valid token.

87
00:05:48,880 --> 00:05:55,960
No problem with it whatsoever because at no point in time did we go over to our service and check to

88
00:05:55,960 --> 00:05:58,960
see if this user should have access.

89
00:05:58,970 --> 00:06:00,860
We're 100 percent decoupled from this thing.

90
00:06:00,880 --> 00:06:02,230
There's no coupling whatsoever.

91
00:06:02,230 --> 00:06:05,450
We don't care what the art service has to say.

92
00:06:05,470 --> 00:06:09,910
So even though the auto service is 100 percent certain that this user should not have access to our

93
00:06:09,910 --> 00:06:15,250
application at no point using option number two because remember that's what we're discussing here.

94
00:06:15,250 --> 00:06:20,410
At no point with option number two do we ever go over to that service to figure out whether or not this

95
00:06:20,410 --> 00:06:28,490
person is still authenticated so that is the core issue with this approach even though we get this fantastic

96
00:06:28,520 --> 00:06:30,500
separation of services.

97
00:06:30,500 --> 00:06:32,210
We don't have any dependencies.

98
00:06:32,300 --> 00:06:37,790
There are still going to be scenarios where we tried to update data in one location tied to a user status

99
00:06:38,390 --> 00:06:41,780
but all the other services are not going to hear about that update.

100
00:06:41,840 --> 00:06:42,680
They don't know.

101
00:06:42,890 --> 00:06:48,080
They don't have any logic to be told hey this user is now banned or something like that because there's

102
00:06:48,080 --> 00:06:54,640
no direct connection between the two but that is the fundamental problem with option number two.

103
00:06:54,660 --> 00:07:00,510
So hopefully now you can start to see why all this authentication stuff is a really nasty thing.

104
00:07:00,510 --> 00:07:01,800
It is an unsolved problem.

105
00:07:01,830 --> 00:07:05,180
There's no single solution out there that is just the right way to do it.

106
00:07:05,220 --> 00:07:10,260
We have to pick the best way out of all the options we have available and we can also try to figure

107
00:07:10,260 --> 00:07:15,060
out some clever ways to work around some of these restrictions.

108
00:07:15,200 --> 00:07:19,470
OK so now that we see that handle this stuff is way more complicated than you might guess.

109
00:07:19,470 --> 00:07:21,770
At first glance let's take a pause right here.

110
00:07:21,790 --> 00:07:25,830
We're gonna come back the next video and I'm going to tell you about the solution that we are going

111
00:07:25,830 --> 00:07:31,830
to take even though it still has some downsides so quick pause continue in just a minute.