WEBVTT 00:00.150 --> 00:06.280 Hello everyone and welcome to this very important lecture about authentication in January's framework. 00:06.300 --> 00:10.050 Let's start off by giving a definition of authentication. 00:10.050 --> 00:17.460 We can define authentication as the system that lets us associate a series of ID credentials to an incoming 00:17.460 --> 00:24.660 request obtaining critical information such as for example the specific user who sent the request. 00:24.810 --> 00:30.840 As we've seen in the previous lectures we can then use a system of permissions to decide whether or 00:30.840 --> 00:32.980 not to accept the incoming request. 00:33.150 --> 00:39.960 For example based on the type of user who sent it such as admin users basic users and so on. 00:39.960 --> 00:45.790 It is therefore important to underline the difference between authentication and permissions. 00:45.900 --> 00:53.370 See authentication is always run at the very start of our views before the authorization checks occur 00:53.640 --> 00:58.060 and before any other code is allowed to be executed. 00:58.200 --> 01:02.340 Authentication by itself won't allow or disallow an incoming request. 01:02.430 --> 01:08.700 It seen pleading defies the credentials that a request was made with January's framework provides us 01:08.730 --> 01:12.800 different authentication systems out of the box. 01:12.840 --> 01:19.180 In this lesson we're going to talk about the most important ones evaluating data processing cards the 01:19.200 --> 01:23.130 most appropriate use cases and implementation details. 01:23.130 --> 01:29.760 We're also going to talk about a new authentication standard called JWT that can be easily implemented 01:29.770 --> 01:34.600 in January's framework with the help of some third party packages. 01:34.830 --> 01:40.060 The first authentication system we were going to talk about is called basic authentication. 01:40.080 --> 01:46.270 It's the most primitive and the least secure authentication system provided by January's framework. 01:46.350 --> 01:49.040 The request response cycle looks like these. 01:49.200 --> 01:55.550 First of all the client makes their age GDP request to the server and the server responds with their 01:55.560 --> 02:04.530 age GDP for 0 1 and authorize a response containing their w w w authenticate ed explaining how to authenticate 02:04.770 --> 02:12.600 for example w w w authenticate basic then the client sends its authentication credentials in eBay's 02:12.700 --> 02:20.400 64 we have the authorization header authentication credentials are EHR and encrypted and because of 02:20.400 --> 02:24.870 that you can start to understand why this is the most primitive and the least secured authentication 02:24.870 --> 02:26.130 system we have. 02:26.130 --> 02:33.060 What happens next is that the server evaluates the access credentials and responds with the 200 or 4 02:33.120 --> 02:40.500 0 3 status code therefore authorizing or denying the client's request because of its low efficiency 02:40.500 --> 02:47.420 and security standards basic authentication is generally only appropriate for testing and jingoist frameworks. 02:47.430 --> 02:54.030 Documentation suggests if you use basic authentication in production you must ensure that your API is 02:54.120 --> 02:56.330 only available or that HDD. 02:56.350 --> 03:03.740 Yes you should also ensure that your API clients will always request the username and password at login 03:04.200 --> 03:07.860 and will never store those details to persistent storage. 03:07.860 --> 03:10.860 Let's now talk about token authentication. 03:10.860 --> 03:15.710 This is the ideal system for authenticating smartphone and desktop clients. 03:15.760 --> 03:18.450 The request response flow looks like this. 03:18.540 --> 03:25.920 The client sends its authentication credentials once the server checks the credentials and if they are 03:25.920 --> 03:33.420 valid it create an exclusive signed token made of a string of characters that are then sent back to 03:33.420 --> 03:40.000 the client as a response the client sends is talking within the authorization either of every following 03:40.030 --> 03:48.150 request so that the server can then check the received token and a valid will allow the request to proceed. 03:48.150 --> 03:53.400 We will often use these authentication scheme during this section using it with clients that we will 03:53.400 --> 04:00.240 write herself using the request module token authentication is also often used with single page applications 04:00.570 --> 04:06.630 written using frameworks like react and view and oftentimes in such cases the authentication talk and 04:06.630 --> 04:12.540 get saved either in a cookie or in the browser lock local storage but it's very important to underline 04:12.540 --> 04:18.900 that saving the authentication token in local storage is very dangerous as it makes it vulnerable to 04:18.930 --> 04:25.740 access s attacks using a HDP only cookie on the other end is much safer because this way the token can 04:25.770 --> 04:31.740 be accessed via javascript but because of that you are now losing the flexibility that you will get 04:31.890 --> 04:34.130 by using local storage instead. 04:34.220 --> 04:39.690 Regarding single page applications which are a very important topic in this course it might be true 04:39.690 --> 04:45.030 that there is no authentication scheme that is universally accepted by the development community as 04:45.060 --> 04:47.630 each project clearly has different requirements. 04:47.640 --> 04:54.840 However it is always very important to opt for a secure and reliable solutions whenever possible for 04:54.840 --> 04:56.760 circumstances like ours. 04:56.830 --> 05:03.790 Gen coders frameworks or official documentation just to use session authentication This is precisely 05:03.790 --> 05:08.050 what we're going to doing the last section of the course in the final project. 05:08.050 --> 05:13.300 We are going to build even though to be honest we are also going to implement token authentication because 05:13.300 --> 05:19.600 we can implement more than one system within our projects so that if we wanted to we could also access 05:19.660 --> 05:24.310 our Web service using a client for example such as a smartphone client. 05:24.310 --> 05:30.760 And in fact as we've talked about in the previous lectures about rest and it's core concepts one of 05:30.760 --> 05:37.360 the most important features of the API first approach is that we can use the same API clearly to communicate 05:37.390 --> 05:39.820 with all sorts of different clients. 05:39.820 --> 05:42.640 Let's talk about session authentication now. 05:42.870 --> 05:48.880 This authentication scheme uses Jangles the fall session backend for authentication session authentication 05:49.120 --> 05:56.050 is the safest and most appropriate way for authenticating Ajax clients that are running the same session 05:56.050 --> 05:58.280 context as your Web site. 05:58.390 --> 06:01.220 It uses a combination of sessions and cookies. 06:01.330 --> 06:06.070 As we've said this is the authentication scheme that we will use in the final project. 06:06.070 --> 06:07.670 So how does it work. 06:07.720 --> 06:10.720 The request response cycle looks like this. 06:10.810 --> 06:17.800 First of all users send data authentication credentials duplicate using a logging form the server checks 06:17.800 --> 06:25.320 the data and if correct it creates a corresponding session object that will be saved in their database. 06:25.510 --> 06:32.530 Sending back to the client a session I.D. decision I.D. gets saved in a cookie in the browser and will 06:32.530 --> 06:36.190 be part of every future request to the server. 06:36.290 --> 06:42.910 If we check it every time when the client logs out the session I.D. is destroyed by both the client 06:42.970 --> 06:49.420 and the server and a new one will be created at the next location if successful yet indicated using 06:49.420 --> 06:56.080 session authentication Django will provide us the corresponding use that object accessible via a request 06:56.230 --> 07:02.830 not user y for non authenticated requests and anonymous user instance will be provided instead. 07:02.890 --> 07:09.760 Very important once authenticated with session authentication the framework will require a valid C as 07:09.850 --> 07:18.880 R F token to be sent for any unsafe TTP method requests such as as we said put patch post ended it. 07:19.000 --> 07:25.600 The C S are f token is an important cross site the request for Jedi vulnerability protection and we 07:25.600 --> 07:30.620 will seal to properly included in Affleck was in the final project and as a bonus. 07:30.640 --> 07:38.080 Let's now talk about Jason Webb Dawkins JWT or Jason Webb token is a new standup which can be used for 07:38.080 --> 07:39.730 token based authentication. 07:39.730 --> 07:46.000 One of the main differences with other talking based standards is that because of their structure JWT 07:46.000 --> 07:49.170 tokens do not require database validation. 07:49.180 --> 07:52.760 Jason Webb tokens can be easily used in a jungle as free more power. 07:52.760 --> 07:59.040 The rest api using the Django framework simple JWT baggage which can be installed via a peep. 07:59.050 --> 08:05.140 We are not going to see how to implement these specific package but by the end of the course you will 08:05.140 --> 08:08.580 have enough knowledge to be able to integrate it by yourself. 08:08.590 --> 08:10.000 That was it for this lecture. 08:10.000 --> 08:11.170 See you in the next one. 08:11.200 --> 08:16.600 Well we're going to learn how to implement registration and authentication and points in our arrest 08:16.690 --> 08:17.500 API. 08:17.560 --> 08:19.780 Using the Django test of package.