1 00:00:01,200 --> 00:00:05,790 In this video we're going to decide whether we should be making use of Jason Webb tokens or cookies. 2 00:00:05,790 --> 00:00:08,690 Now remember this is not an either or decision. 3 00:00:08,700 --> 00:00:12,170 Cookie is in Jason with tokens are two very different things. 4 00:00:12,180 --> 00:00:16,440 The implication here usually when we say that we're using cookie based authentication. 5 00:00:16,440 --> 00:00:21,360 The implication is that we have a cookie that is going to store some kind of encoded token inside of 6 00:00:21,360 --> 00:00:26,460 it and that's going to be encrypted in some way that the user cannot access the information inside there. 7 00:00:26,460 --> 00:00:28,530 So again these are two different things. 8 00:00:28,620 --> 00:00:33,480 But usually when referred to cookie based authentication we're talking about using a very particular 9 00:00:33,480 --> 00:00:36,810 style of off and storing some information inside that cookie. 10 00:00:37,050 --> 00:00:41,220 At any rate let's just take a look at a couple of diagrams and get a better idea of the requirements 11 00:00:41,280 --> 00:00:47,160 of our application and which of these two approaches is going to satisfy those requirements. 12 00:00:47,160 --> 00:00:52,320 OK I've taken a series of diagrams that we've looked at in the past and I've added it in a couple of 13 00:00:52,320 --> 00:00:58,170 notes to each of them the notes I've added in are pointing out some particular aspect of our application 14 00:00:58,650 --> 00:01:05,000 and what that particular aspect is kind of implying or requiring of our authentication mechanism so 15 00:01:05,070 --> 00:01:09,270 in this diagram right here remember we imagine that we had our order service and we were making a request 16 00:01:09,270 --> 00:01:11,160 to say purchase a ticket. 17 00:01:11,160 --> 00:01:16,050 And so inside of our ticket purchase lodge logic we probably needed to figure out whether or not that 18 00:01:16,050 --> 00:01:22,360 user is logged in and OK we can use adjacent token or some cookie based approach for that no problem. 19 00:01:22,380 --> 00:01:26,930 And then after that we probably needed to decide whether or not this user can purchase a ticket. 20 00:01:27,300 --> 00:01:31,890 So maybe whether or not they have billing setup in their account whether or not they have a credit card 21 00:01:32,190 --> 00:01:38,420 or something similar to that that step right there that implication that we need to somehow figure out 22 00:01:38,420 --> 00:01:44,300 whether or not this user or details about this user really implies that our authentication mechanism 23 00:01:44,390 --> 00:01:48,850 needs to tell us information about the person who was just authenticated. 24 00:01:48,920 --> 00:01:53,900 In other words we can't just have some mechanism that says yes this user is authenticated or no they 25 00:01:53,900 --> 00:01:54,740 are not. 26 00:01:54,740 --> 00:02:00,770 Instead this authentication mechanism has to tell us yes this person is authenticated and here is some 27 00:02:00,770 --> 00:02:01,740 information about them. 28 00:02:02,150 --> 00:02:07,070 Here's their user I.D. Here's their email years whether or not they have a credit card tied to their 29 00:02:07,070 --> 00:02:08,010 account. 30 00:02:08,030 --> 00:02:15,130 So we need to have some option or ability to store information inside of our off mechanism that is requirement 31 00:02:15,130 --> 00:02:19,350 Number one here's requirement number two. 32 00:02:19,350 --> 00:02:23,850 So this is similar to the diagram we're just looking at but I customized a couple of things inside of 33 00:02:23,850 --> 00:02:26,640 it to just imagine a new scenario. 34 00:02:26,640 --> 00:02:31,170 Let's imagine that our application has the ability to create free coupons. 35 00:02:31,170 --> 00:02:35,340 So these are coupon codes that allow people to get free tickets. 36 00:02:35,400 --> 00:02:41,010 Of course we probably do not want any arbitrary user to be able to access this root handler and start 37 00:02:41,010 --> 00:02:44,480 creating free tickets that would be catastrophic really bad. 38 00:02:44,520 --> 00:02:49,200 So that would probably be something that we would want to limit to maybe administration users the only 39 00:02:49,200 --> 00:02:55,620 admins can make a request that will create a free coupon code so we can imagine that an admin user would 40 00:02:55,620 --> 00:03:00,650 make a request to create this coupon code it would go to who knows what service maybe order service 41 00:03:00,660 --> 00:03:02,000 doesn't really matter. 42 00:03:02,190 --> 00:03:08,190 Inside there we would access some free coupon creation logic and the first thing we do is check to see 43 00:03:08,190 --> 00:03:11,520 if that person is logged in if they are immediately after that. 44 00:03:11,610 --> 00:03:17,610 We would definitely need to check whether or not this person is authorized to create free coupons. 45 00:03:17,610 --> 00:03:23,800 So we need to decide whether or not this is an admin user so this little step right here even though 46 00:03:23,830 --> 00:03:27,940 our application is not going to do this we could very easily imagine scenarios where we would need to 47 00:03:27,940 --> 00:03:30,040 have something similar to this that separate. 48 00:03:30,040 --> 00:03:36,460 There is really implying that our off mechanism has to include some amount of authorization information 49 00:03:36,910 --> 00:03:39,560 we need to know more information about this user. 50 00:03:39,610 --> 00:03:40,270 Are they user. 51 00:03:40,270 --> 00:03:41,590 Are they an admin. 52 00:03:41,590 --> 00:03:43,120 What's their role. 53 00:03:43,120 --> 00:03:47,780 Stuff like that all right onto the next diagram. 54 00:03:47,850 --> 00:03:50,860 Now this diagram right here was in an optional video. 55 00:03:50,880 --> 00:03:55,740 This was tied to the video where we discussed possible ways of solving that issue where we could be 56 00:03:55,740 --> 00:04:00,750 on a user but they would still have access to our application in this option number two approach that 57 00:04:00,750 --> 00:04:07,780 we're using inside of our app so one way that we discussed to solve this issue was to have a auth mechanism 58 00:04:07,840 --> 00:04:11,730 that would expire after some set of time. 59 00:04:11,770 --> 00:04:16,780 So this is really implying that whatever off mechanism we are going to use it has to have a built in 60 00:04:16,780 --> 00:04:18,790 way and a super secure way. 61 00:04:18,790 --> 00:04:23,830 In other words we would not want a user to be able to tamper with this in some way of expiring our auth 62 00:04:23,830 --> 00:04:30,620 mechanism after a set period of time a very precise period of time so maybe 15 minutes 20 minutes 10 63 00:04:30,640 --> 00:04:32,470 days whatever else. 64 00:04:32,500 --> 00:04:35,760 So that's the next requirement of our off mechanism. 65 00:04:35,770 --> 00:04:35,980 All right. 66 00:04:35,980 --> 00:04:37,910 Just one last one right here. 67 00:04:38,000 --> 00:04:42,850 So last thing I want you to recall is that we are going to have a browser application maybe a mobile 68 00:04:42,850 --> 00:04:44,200 app whatever else it is. 69 00:04:44,320 --> 00:04:48,370 And this is going to be eventually be sending a request to our different services. 70 00:04:48,610 --> 00:04:54,100 One of the big benefits of using a micro services approach is that each of our different services can 71 00:04:54,100 --> 00:05:00,400 be built using a different backend language so we might have the odd service written with node and expressed 72 00:05:00,850 --> 00:05:04,780 orders might be with Ruby on Rails and payments might be with Java spring. 73 00:05:04,780 --> 00:05:11,110 So this is really implying that whatever auth mechanism we decide to use it has to be easily understood 74 00:05:11,170 --> 00:05:13,070 by many different languages. 75 00:05:13,210 --> 00:05:17,710 Because with this option number two fundamental fundamental approach that you and I are using we are 76 00:05:17,710 --> 00:05:22,390 saying that each of these services are in charge of deciding whether or not to authenticate a given 77 00:05:22,390 --> 00:05:23,730 incoming request. 78 00:05:23,740 --> 00:05:29,350 So whatever mechanism we decide to use here just on web token or something else it has to be easily 79 00:05:29,380 --> 00:05:37,100 implementable with Express or Ruby or Java also given the fact that each of these different services 80 00:05:37,100 --> 00:05:39,950 are going to need to somehow authenticate a user. 81 00:05:39,950 --> 00:05:44,770 We probably do not want to force any storage requirements on these services as well. 82 00:05:44,810 --> 00:05:49,760 In other words if we are deciding on some off mechanism that is going to require us to have some back 83 00:05:49,760 --> 00:05:55,340 end server or me a back end database just to store information to support that off mechanism that would 84 00:05:55,340 --> 00:05:56,360 probably be bad. 85 00:05:56,390 --> 00:06:02,360 We don't want to force say our order service to have some kind of specialized database to store information 86 00:06:02,420 --> 00:06:07,270 just to support our off mechanism that would be probably not that great. 87 00:06:07,280 --> 00:06:07,480 All right. 88 00:06:07,490 --> 00:06:09,180 So let's summarize all this stuff up. 89 00:06:09,240 --> 00:06:11,540 These are the requirements for our off mechanism. 90 00:06:11,600 --> 00:06:16,610 First off we have to store information about a user so maybe their user I.D. their email or something 91 00:06:16,610 --> 00:06:25,040 like that within the mechanism itself that is closely coupled with this last item down here so if we 92 00:06:25,040 --> 00:06:30,110 are storing information about that user it has to be inside the off mechanism and it must not require 93 00:06:30,110 --> 00:06:33,510 us to have some kind of backing data store. 94 00:06:33,510 --> 00:06:37,170 Next up we have to build a store some authorization info inside there as well. 95 00:06:37,230 --> 00:06:42,690 So whether or not this person is an admin a normal user or something else we have to have a built in 96 00:06:42,780 --> 00:06:44,690 and tamper resistant way. 97 00:06:44,760 --> 00:06:51,300 So users can appeal to muddy around with this or kind of fool us to expire or invalidate that auth mechanism 98 00:06:51,450 --> 00:06:56,730 automatically without us having to reach out to a user's browser or something like that because we can't 99 00:06:56,730 --> 00:07:00,850 do that and tried to invalidate their off mechanism. 100 00:07:00,850 --> 00:07:06,060 And then finally whatever we choose has to be easily understood between these different languages. 101 00:07:06,090 --> 00:07:11,940 So suffice to say all these requirements right here are very heavily steering us towards a Jason web 102 00:07:11,940 --> 00:07:13,960 token approach. 103 00:07:14,030 --> 00:07:19,970 The reason for this it satisfies Well obviously all these different issues right here on a percent. 104 00:07:19,970 --> 00:07:24,200 Jason Webb tokens we can store only arbitrary information we want about a user. 105 00:07:24,200 --> 00:07:29,480 There are even built in properties of Jason with tokens that lend its to a handling authorization very 106 00:07:29,480 --> 00:07:29,960 well. 107 00:07:30,770 --> 00:07:34,340 Jason Webb tokens can encode code expiration information. 108 00:07:34,570 --> 00:07:39,080 They might be saying hey Steven cookies can do that as well we can have cookies expire after a set period 109 00:07:39,080 --> 00:07:39,920 of time. 110 00:07:39,950 --> 00:07:41,840 Well not quite. 111 00:07:41,840 --> 00:07:48,770 You see we can set some expiration on a cookie but that is us kind of politely asking a browser to expire 112 00:07:48,770 --> 00:07:52,510 the cookie cookie expiration is handled by the browser. 113 00:07:52,760 --> 00:07:54,670 So the browser is going to receive a cookie. 114 00:07:54,740 --> 00:07:59,440 It's going to see that we ask the browser to expire that after say 20 days or something like that. 115 00:07:59,480 --> 00:08:03,230 And after 20 days the browser will expire that cookie for us. 116 00:08:03,230 --> 00:08:07,850 But a user can very easily copy that cookie information and just ignore the expiration date on there 117 00:08:08,060 --> 00:08:13,670 and continue using that cookie in the off mechanism or auth information side there at some point time 118 00:08:13,730 --> 00:08:16,420 in the future even beyond that expiration date. 119 00:08:16,480 --> 00:08:22,460 A Jason web token however is going to encode the expiration time in itself and as soon as the Jason 120 00:08:22,460 --> 00:08:24,760 web token expires then that's it. 121 00:08:24,770 --> 00:08:32,280 It will not be valid anymore Jason what tokens have fantastic support between different languages. 122 00:08:32,330 --> 00:08:36,470 So every language out there you're going to find an official implementation for handling Jason Webb 123 00:08:36,470 --> 00:08:42,950 tokens if we use solely cookie based authentication where we kind of create some kind of custom token 124 00:08:42,980 --> 00:08:44,360 and store inside of a cookie. 125 00:08:44,360 --> 00:08:49,610 It turns out that a lot of these different custom cookie implementations will vary significantly between 126 00:08:49,610 --> 00:08:50,700 different languages. 127 00:08:50,840 --> 00:08:55,340 And if you're super curious I can even show you instances of that with some popular cookie libraries 128 00:08:55,340 --> 00:09:01,020 used in the no J.S. world would be kind of hard to create a cookie that is signed securely. 129 00:09:01,040 --> 00:09:08,150 So has some actual and a secure or encryption around it using no J.S. or express and then reuse that 130 00:09:08,180 --> 00:09:10,110 over in the Ruby on Rails world. 131 00:09:10,130 --> 00:09:12,420 That would be kind of challenging. 132 00:09:12,540 --> 00:09:17,320 And then finally Jason Webb tokens do not strictly require us to have some kind of backing data store 133 00:09:17,340 --> 00:09:20,760 to identify this user now as opposed to cookies. 134 00:09:20,760 --> 00:09:26,130 You will see a lot of people who will use cookies they're going to try to store just say a session I.D. 135 00:09:26,130 --> 00:09:26,910 inside the cookie. 136 00:09:26,910 --> 00:09:31,190 That refers to some session that is stored on a back in server that is not strictly required. 137 00:09:31,200 --> 00:09:35,820 We can't store again any arbitrary information we want inside of a cookie but you're going to see that 138 00:09:35,820 --> 00:09:40,290 a lot of people out there a lot of methodology says that cookie based authentication you're going to 139 00:09:40,290 --> 00:09:46,130 store some kind of session I.D. and so of course that does infer or imply that you will have a back 140 00:09:46,130 --> 00:09:49,380 in data store on the server which again we probably do not want to do. 141 00:09:50,280 --> 00:09:50,580 OK. 142 00:09:50,580 --> 00:09:56,310 So again Jason token that's what we're going to use now that makes it sound really easy and hey these 143 00:09:56,310 --> 00:09:59,310 are great reasons for that but we're still not quite done here. 144 00:09:59,310 --> 00:10:05,460 Remember one thing we looked at earlier when we decide to use a Jason Webb token that's not the end 145 00:10:05,550 --> 00:10:06,930 of the story. 146 00:10:07,020 --> 00:10:10,410 Jason what tokens are just an authentication mechanism. 147 00:10:10,410 --> 00:10:16,030 They're a piece of data that proves that someone is logged in and store some information about the user. 148 00:10:16,050 --> 00:10:21,810 We still have to somehow communicate this information between our browser and our server. 149 00:10:21,810 --> 00:10:28,390 We can do it either manually to a degree using these headers or sticking it into the body of a request. 150 00:10:28,650 --> 00:10:35,200 Or alternatively we can have the browser handle it for us using still this kind of cookie based idea. 151 00:10:35,220 --> 00:10:40,470 Now remember this is where there really is a difference between cookies Becky based authentication and 152 00:10:40,500 --> 00:10:41,910 Jason web tokens. 153 00:10:41,910 --> 00:10:46,620 In this case we're saying that we're going to use a Jason we've token to store our off information but 154 00:10:46,620 --> 00:10:48,760 the cookie is going to be the transport mechanism. 155 00:10:48,780 --> 00:10:54,150 That's how we actually shove or move the cookie around between the browser and the server. 156 00:10:54,180 --> 00:10:57,600 So we still have to decide how we're going to move this token around. 157 00:10:57,600 --> 00:10:59,180 Let's do that in just a moment.