WEBVTT 00:01.200 --> 00:05.340 So in this section of the course, we're going to implement some authentication and there are lots of 00:05.340 --> 00:06.650 different ways to do this. 00:07.200 --> 00:12.180 So if you think about it, when we log a user in, something has to happen. 00:12.180 --> 00:16.440 We have to authenticate that that user is valid, that they're active, that they have permissions, 00:16.440 --> 00:17.340 whatever it may be. 00:18.390 --> 00:23.160 So how authentication works varies depending on the kind of Web application we're talking about. 00:23.430 --> 00:31.020 So for a website that has log in and doesn't have an API, for example, we actually can use sessions, 00:31.320 --> 00:37.020 will allow the user to fill out a login form, will have some handler that validates the username and 00:37.020 --> 00:42.370 password and decides whether or not that person can log in if that person can log in. 00:42.750 --> 00:48.720 We typically set some kind of sessional variable like authenticated is equal to true or whatever the 00:48.720 --> 00:49.490 case may be. 00:49.710 --> 00:54.790 And then until that session expires or the user logs out, they can just do whatever they want. 00:54.810 --> 00:58.590 So we validate that central variable on every request. 00:59.400 --> 01:01.270 With the backend, it's a little bit different. 01:01.950 --> 01:06.570 Typically, we use tokens and there are lots of different kinds of tokens that we can use. 01:06.600 --> 01:07.800 So let's have a look at a few of them. 01:07.830 --> 01:08.730 These are the major ones. 01:09.600 --> 01:16.320 We have HDB basic authentication, which is really, really simple to implement and it's relatively 01:16.320 --> 01:18.870 secure, but it's typically very, very slow. 01:19.200 --> 01:24.480 The big advantage, of course, is that you don't have to do a lot of programming, but typically it's 01:24.480 --> 01:26.250 not an ideal solution. 01:26.250 --> 01:31.280 If you're going to have any amount of traffic whatsoever, then we have simple tokens. 01:31.800 --> 01:34.250 We have a token that just is valid. 01:34.260 --> 01:39.290 We validate whether or not the token is valid on the back end with every request to the back end. 01:40.170 --> 01:43.560 And the difficulty with this one is that you have to validate the token. 01:43.560 --> 01:45.400 You have to decide when it expires. 01:45.450 --> 01:50.100 There's a fair bit of programming required to make that happen, and that's typically not very common 01:50.100 --> 01:51.000 in my experience. 01:51.000 --> 01:57.210 I've seen it, but I see other forms of authentication much more frequently than we have stateful tokens. 01:57.210 --> 02:00.770 And these are tokens that we actually validate the user. 02:00.780 --> 02:07.290 We typically store the validation, the token or a hash of the token and an expiry date in the database. 02:07.620 --> 02:10.890 And we can manage the tokens that are valid any time we want to. 02:10.890 --> 02:16.980 If we want to, for example, invalidate a given user, we simply remove that entry from the database 02:16.980 --> 02:18.330 or we market has expired. 02:18.330 --> 02:20.900 And the next time they make a request, they can't do anything. 02:22.050 --> 02:28.170 Then we have one that has a lot of mindshare, JSON, Web tokens, JWT and they are stateless tokens, 02:28.290 --> 02:32.310 the token and it's expire actually stored in the token itself. 02:33.590 --> 02:38.790 A lot of people are using JSON Web tokens these days and in fact I've used it in another course and 02:38.790 --> 02:39.900 they work reasonably well. 02:40.140 --> 02:45.690 The big disadvantage is that you can't revoke a token on a per token basis. 02:45.960 --> 02:51.330 If, for example, you have some user that's gone rogue, the only way to ensure that you get that user 02:51.330 --> 02:55.350 off the system instantly is to revoke all of the tokens all at once. 02:55.350 --> 02:57.110 And that's not an ideal situation. 02:57.660 --> 03:03.600 And the other problem with JWT is, in my experience, is that it takes an awful lot of client side 03:03.600 --> 03:09.300 programming to refresh the token when necessary, to validate the token. 03:09.300 --> 03:12.930 And it's a lot of work, but it works really well and I've used them in the past. 03:13.650 --> 03:15.150 Then we have API keys. 03:15.150 --> 03:19.380 And if you've ever worked with GitHub APIs or something like that, you're probably familiar with it 03:19.380 --> 03:20.730 and we're not going to do that one. 03:20.940 --> 03:25.800 But it's something that exists in the same way off to you can authenticate a user using their Google 03:25.800 --> 03:27.390 account or their Facebook account. 03:27.870 --> 03:29.420 And that's got a lot of popularity. 03:29.670 --> 03:32.430 But of course, the user has to have an account on that system. 03:32.850 --> 03:37.170 The one we're going to use in this course is stateful tokens. 03:37.170 --> 03:39.530 And it's a pretty straightforward approach. 03:39.540 --> 03:40.770 It works really well. 03:41.130 --> 03:43.650 And that's what we'll be doing in the coming lecture's.