1 00:00:01,330 --> 00:00:06,490 We are finally to the last step of our sign up process so we are now considering a user to be signed 2 00:00:06,490 --> 00:00:06,850 in. 3 00:00:06,950 --> 00:00:10,810 And that means we need to somehow generate a cookie or Jason web token. 4 00:00:10,810 --> 00:00:15,490 Something like that and send it back over to the user and the user should then use that token. 5 00:00:15,490 --> 00:00:20,620 That cookie whatever it is to attempt to access other services inside of application and prove that 6 00:00:20,620 --> 00:00:27,190 they are actually signed in now handling authentication handling the process of making sure that someone 7 00:00:27,190 --> 00:00:32,590 is sending us request who is logged into our application is deceptively challenging in micros services 8 00:00:32,940 --> 00:00:37,660 are going to first start off with a little disclaimer here handling it user authentication. 9 00:00:37,690 --> 00:00:43,090 So in other words giving a user a cookie a Jason web token or something similar and allowing them to 10 00:00:43,090 --> 00:00:48,610 access other services inside of our app is a challenging problem that is not really solved. 11 00:00:48,610 --> 00:00:52,640 In other words there is not really a perfect solution to handling this stuff. 12 00:00:52,690 --> 00:00:57,290 There is not some strategy where we just say oh yeah I use a cookie or use adjacent web token. 13 00:00:57,580 --> 00:01:00,640 And tonight everything works that doesn't exist. 14 00:01:00,640 --> 00:01:05,410 So instead with micros services and in the context of this course I'm going to try to outline a couple 15 00:01:05,410 --> 00:01:11,650 of different possible approaches in handling authentication approaches and how we can say hey user here's 16 00:01:11,650 --> 00:01:13,660 a cookie or here's a token of sorts. 17 00:01:13,660 --> 00:01:19,560 Give this to us in the future and how we can decide whether or not a user truly is authenticated. 18 00:01:19,730 --> 00:01:23,270 We're going to take a look at these different solutions and I'm going to eventually show you one that 19 00:01:23,270 --> 00:01:28,410 is going to work but it is definitely by no means perfect in nature. 20 00:01:28,430 --> 00:01:29,880 OK so enough this disclaimer. 21 00:01:29,930 --> 00:01:31,310 Let's get to it. 22 00:01:31,370 --> 00:01:37,110 So I want you to imagine for a second that eventually inside of our application which remember is all 23 00:01:37,110 --> 00:01:41,490 about selling tickets and whatnot that we will eventually have some kind of service called the order 24 00:01:41,490 --> 00:01:47,460 service and inside this order service the goal is to allow users to purchase a ticket so we can imagine 25 00:01:47,460 --> 00:01:52,320 that inside that service we'll probably have something like ticket purchasing logic probably a request 26 00:01:52,320 --> 00:01:54,040 handler something like that. 27 00:01:54,460 --> 00:01:58,410 And we could definitely imagine that at some point time someone's going to send a request to the service 28 00:01:58,410 --> 00:02:02,990 with the goal of purchasing a ticket maybe in the body of the ticket they'll have the ticket I.D. or 29 00:02:03,070 --> 00:02:05,960 be the body to request the ticket I.D. or something like that. 30 00:02:06,000 --> 00:02:10,610 And of course along with this request a user is going to have to prove that they are authenticated with 31 00:02:10,610 --> 00:02:11,930 our application. 32 00:02:12,060 --> 00:02:16,800 So along with the request they're going to have to include some Jason web token some cookie or something 33 00:02:16,800 --> 00:02:24,590 similar something to say I am signed in then inside of our request handler we are going to have to have 34 00:02:24,590 --> 00:02:27,540 some logic to say is this person actually signed in. 35 00:02:27,620 --> 00:02:30,020 Did they give us a valid Jason web token. 36 00:02:30,020 --> 00:02:35,530 Did they give us some cookie with some authentication information side of it and we need to decide whether 37 00:02:35,530 --> 00:02:41,610 or not this person who's sending us this request is actually signed into our app so this whole discussion 38 00:02:41,610 --> 00:02:46,560 we are about to have and this whole disclaimer right here about user authentication really comes down 39 00:02:46,560 --> 00:02:53,640 to how we answer this question how do we decide whether or not someone is logged in in a micro services 40 00:02:53,700 --> 00:02:54,630 app. 41 00:02:54,630 --> 00:02:57,440 This is way more challenging and deceptive than you would think. 42 00:02:57,960 --> 00:03:04,270 So again I'm going to show you two big approaches here is approach number one now on this first approach 43 00:03:04,330 --> 00:03:05,700 I've labeled it fundamental. 44 00:03:05,740 --> 00:03:10,270 Option number one the reason I'm putting the word fundamental in here is that I'm going to show you 45 00:03:10,270 --> 00:03:16,180 two general approaches to general strategies but there are very much variations of each of these at 46 00:03:16,180 --> 00:03:21,040 the end of the day though all the different strategies out there really come down to two very fundamental 47 00:03:21,040 --> 00:03:21,840 principles. 48 00:03:21,890 --> 00:03:24,040 That's why I'm calling this fundamental option number one. 49 00:03:24,070 --> 00:03:28,030 Again you're going to find variations of this but it really comes down to this idea. 50 00:03:28,120 --> 00:03:34,090 The idea is that we are going to allow individual services to rely on some centralized authentication 51 00:03:34,090 --> 00:03:39,990 service to decide whether or not a user is logged in so let's again imagine that same scenario where 52 00:03:39,990 --> 00:03:43,840 someone's make your request to purchase a ticket it goes into our order service. 53 00:03:43,890 --> 00:03:47,920 We then need to ask and decide whether or not this person is logged in. 54 00:03:47,970 --> 00:03:53,160 So to answer that question with fundamental option number one we might take that Jace on a Web token 55 00:03:53,250 --> 00:03:59,910 or that cookie or whatever else and send it in some synchronous request off to our authentication service 56 00:04:00,480 --> 00:04:03,840 and the authentication service might have some logic to take a look at that. 57 00:04:03,840 --> 00:04:09,210 Jason a web token that cookie or whatever else and aside if this user is authenticated and so it would 58 00:04:09,210 --> 00:04:14,490 be up to the authentication service to send a response back over now remember I'm using the term here 59 00:04:14,490 --> 00:04:19,770 sync request not in the world of javascript but in the world of micros services in the world micros 60 00:04:19,770 --> 00:04:25,470 services sync request refers to a direct request from one service to another one that does not make 61 00:04:25,470 --> 00:04:33,790 use of events or event buses or anything like that so the downside of fundamental option one really 62 00:04:33,790 --> 00:04:38,110 shares all the same downsides as synchronous communication in general. 63 00:04:38,200 --> 00:04:40,260 If we put together this kind of solution right here. 64 00:04:40,300 --> 00:04:45,840 Think about what would happen if the authentication service just mysteriously went down one day. 65 00:04:45,880 --> 00:04:52,420 If that thing crashed or just disappeared all of a sudden no one no service inside of our entire application 66 00:04:52,420 --> 00:04:58,240 can decide if a person is logged in and that means that any request that requires us to decide if a 67 00:04:58,240 --> 00:05:02,000 person is authenticated is automatically going to fail. 68 00:05:02,020 --> 00:05:04,750 So by using this fundamental option number one. 69 00:05:04,750 --> 00:05:11,390 Well we are going to be in a world of hurt if anything goes wrong with our authentication service. 70 00:05:11,430 --> 00:05:15,670 That's a very clear downside to fundamental option number one. 71 00:05:15,690 --> 00:05:16,810 All right let's move on. 72 00:05:16,810 --> 00:05:19,190 We're going to show you some other pros and cons as we go on. 73 00:05:19,200 --> 00:05:21,710 But for right now let's just go to the next option. 74 00:05:22,140 --> 00:05:24,200 Now this is option one point one. 75 00:05:24,210 --> 00:05:29,010 So it's really the same as what we're just looking at just about identical in nature but we just kind 76 00:05:29,010 --> 00:05:34,050 of move some stuff around at the end of the day fundamental option number one is still very very close 77 00:05:34,050 --> 00:05:41,030 to option number one because we are still relying upon the service 100 percent of the time. 78 00:05:41,050 --> 00:05:44,980 The only reason I'm showing you one point one right here is to help you understand that yes there are 79 00:05:44,980 --> 00:05:47,210 variations in these strategies. 80 00:05:47,230 --> 00:05:51,940 So with this strategy we would say that any request coming into our application would need to go through 81 00:05:51,940 --> 00:05:57,070 some central gateway of sorts that would authenticate the incoming request. 82 00:05:57,070 --> 00:06:01,150 So whenever a user makes a request to purchase a ticket rather than going directly to the order service 83 00:06:01,150 --> 00:06:06,970 we would instead have it flow into some authentication gateway or some authentication service of sorts 84 00:06:07,160 --> 00:06:11,490 that would inspect that incoming request and decide if the user is authenticated if they are. 85 00:06:11,530 --> 00:06:14,330 We would then send the request along to the intended destination. 86 00:06:14,470 --> 00:06:16,850 Otherwise we would just reject it right away. 87 00:06:16,910 --> 00:06:22,210 This still shares a lot of the pros and cons of this option number one right here because we would still 88 00:06:22,210 --> 00:06:29,280 have a 100 percent reliance on the authentication service in both cases if this thing ever goes down 89 00:06:30,060 --> 00:06:35,490 or if this thing ever goes down all of a sudden we can not make a single request that requires any kind 90 00:06:35,490 --> 00:06:37,110 of authentication. 91 00:06:37,110 --> 00:06:41,430 Again I'm only showing you this option one point one to say yeah there's variations on these things 92 00:06:41,460 --> 00:06:44,950 but they are at the other day very similar in nature. 93 00:06:44,950 --> 00:06:47,090 Now let's move on to the next option. 94 00:06:47,140 --> 00:06:48,740 What's the really option too. 95 00:06:48,910 --> 00:06:51,030 What's different approach we could take here. 96 00:06:51,040 --> 00:06:55,950 Well here's option number two with fundamental option number two. 97 00:06:56,020 --> 00:07:02,840 We are going to teach each individual service how to decide whether or not a user is authenticated. 98 00:07:02,850 --> 00:07:08,100 So for example whenever someone makes a request to purchase a ticket to our order service and inside 99 00:07:08,100 --> 00:07:10,860 there we need to decide whether or not this person is logged in. 100 00:07:10,860 --> 00:07:15,050 Then we will teach this service how to take a look at the request. 101 00:07:15,060 --> 00:07:20,940 Jason web token cookie whatever we are using and decide whether or not the user is authenticated. 102 00:07:20,960 --> 00:07:26,390 So in this scenario we have no dependency on outside services no dependency on a gateway. 103 00:07:26,490 --> 00:07:28,930 Some other service or anything like that. 104 00:07:29,040 --> 00:07:31,660 Everything is wrapped up inside of one single service. 105 00:07:31,800 --> 00:07:36,840 And if a user ever makes requests to this thing we will immediately and instantly know whether or not 106 00:07:36,840 --> 00:07:38,650 this user is logged in. 107 00:07:38,730 --> 00:07:40,770 And so the upsides this approach are very clear. 108 00:07:40,770 --> 00:07:45,000 We do not have any outside dependency as we did previously on this OTT service. 109 00:07:45,000 --> 00:07:48,680 If you give us a token and it's valid Hey you must be logged in. 110 00:07:48,720 --> 00:07:55,110 We're good to go and we will process your request so it immediately might seem like fundamental option 111 00:07:55,110 --> 00:07:59,130 number two is way better because we don't have any outside dependency. 112 00:07:59,130 --> 00:08:03,000 There is a very clear and immediate downside that you could probably imagine and that is that we're 113 00:08:03,000 --> 00:08:07,880 going to end up duplicating this authentication logic between all of our different services. 114 00:08:07,890 --> 00:08:10,190 I want you know right now that's not a big deal. 115 00:08:10,230 --> 00:08:15,290 We could easily move this authentication logic into a shared library that's used among all of our services. 116 00:08:15,300 --> 00:08:19,800 And so we can really just have very few implementations that get shared all over the place. 117 00:08:19,890 --> 00:08:26,730 So not really concerned about duplicating any of that logic but there are some much more larger fundamental 118 00:08:26,730 --> 00:08:31,020 very critical downsides of fundamental option number two. 119 00:08:31,200 --> 00:08:36,060 You really need to understand these because these the issues around fundamental option number two is 120 00:08:36,060 --> 00:08:41,730 where we are going to start to see that micros services communicating with each other is really really 121 00:08:41,820 --> 00:08:44,060 challenging. 122 00:08:44,060 --> 00:08:45,790 Now this video is running a little bit long. 123 00:08:45,800 --> 00:08:46,730 Let's take a pause right here. 124 00:08:46,730 --> 00:08:51,170 We're gonna come back the next video and I wanted to show you the absolute very critical to understand 125 00:08:51,170 --> 00:08:54,950 downsides of option number two even though it looks like it's really great. 126 00:08:54,950 --> 00:08:57,880 As it stands right now does continue in just a minute.