Hello everyone and welcome to this very important lecture about authentication in January's framework.
Let's start off by giving a definition of authentication.
We can define authentication as the system that lets us associate a series of ID credentials to an incoming
request obtaining critical information such as for example the specific user who sent the request.
As we've seen in the previous lectures we can then use a system of permissions to decide whether or
not to accept the incoming request.
For example based on the type of user who sent it such as admin users basic users and so on.
It is therefore important to underline the difference between authentication and permissions.
See authentication is always run at the very start of our views before the authorization checks occur
and before any other code is allowed to be executed.
Authentication by itself won't allow or disallow an incoming request.
It seen pleading defies the credentials that a request was made with January's framework provides us
different authentication systems out of the box.
In this lesson we're going to talk about the most important ones evaluating data processing cards the
most appropriate use cases and implementation details.
We're also going to talk about a new authentication standard called JWT that can be easily implemented
in January's framework with the help of some third party packages.
The first authentication system we were going to talk about is called basic authentication.
It's the most primitive and the least secure authentication system provided by January's framework.
The request response cycle looks like these.
First of all the client makes their age GDP request to the server and the server responds with their
age GDP for 0 1 and authorize a response containing their w w w authenticate ed explaining how to authenticate
for example w w w authenticate basic then the client sends its authentication credentials in eBay's
64 we have the authorization header authentication credentials are EHR and encrypted and because of
that you can start to understand why this is the most primitive and the least secured authentication
system we have.
What happens next is that the server evaluates the access credentials and responds with the 200 or 4
0 3 status code therefore authorizing or denying the client's request because of its low efficiency
and security standards basic authentication is generally only appropriate for testing and jingoist frameworks.
Documentation suggests if you use basic authentication in production you must ensure that your API is
only available or that HDD.
Yes you should also ensure that your API clients will always request the username and password at login
and will never store those details to persistent storage.
Let's now talk about token authentication.
This is the ideal system for authenticating smartphone and desktop clients.
The request response flow looks like this.
The client sends its authentication credentials once the server checks the credentials and if they are
valid it create an exclusive signed token made of a string of characters that are then sent back to
the client as a response the client sends is talking within the authorization either of every following
request so that the server can then check the received token and a valid will allow the request to proceed.
We will often use these authentication scheme during this section using it with clients that we will
write herself using the request module token authentication is also often used with single page applications
written using frameworks like react and view and oftentimes in such cases the authentication talk and
get saved either in a cookie or in the browser lock local storage but it's very important to underline
that saving the authentication token in local storage is very dangerous as it makes it vulnerable to
access s attacks using a HDP only cookie on the other end is much safer because this way the token can
be accessed via javascript but because of that you are now losing the flexibility that you will get
by using local storage instead.
Regarding single page applications which are a very important topic in this course it might be true
that there is no authentication scheme that is universally accepted by the development community as
each project clearly has different requirements.
However it is always very important to opt for a secure and reliable solutions whenever possible for
circumstances like ours.
Gen coders frameworks or official documentation just to use session authentication This is precisely
what we're going to doing the last section of the course in the final project.
We are going to build even though to be honest we are also going to implement token authentication because
we can implement more than one system within our projects so that if we wanted to we could also access
our Web service using a client for example such as a smartphone client.
And in fact as we've talked about in the previous lectures about rest and it's core concepts one of
the most important features of the API first approach is that we can use the same API clearly to communicate
with all sorts of different clients.
Let's talk about session authentication now.
This authentication scheme uses Jangles the fall session backend for authentication session authentication
is the safest and most appropriate way for authenticating Ajax clients that are running the same session
context as your Web site.
It uses a combination of sessions and cookies.
As we've said this is the authentication scheme that we will use in the final project.
So how does it work.
The request response cycle looks like this.
First of all users send data authentication credentials duplicate using a logging form the server checks
the data and if correct it creates a corresponding session object that will be saved in their database.
Sending back to the client a session I.D. decision I.D. gets saved in a cookie in the browser and will
be part of every future request to the server.
If we check it every time when the client logs out the session I.D. is destroyed by both the client
and the server and a new one will be created at the next location if successful yet indicated using
session authentication Django will provide us the corresponding use that object accessible via a request
not user y for non authenticated requests and anonymous user instance will be provided instead.
Very important once authenticated with session authentication the framework will require a valid C as
R F token to be sent for any unsafe TTP method requests such as as we said put patch post ended it.
The C S are f token is an important cross site the request for Jedi vulnerability protection and we
will seal to properly included in Affleck was in the final project and as a bonus.
Let's now talk about Jason Webb Dawkins JWT or Jason Webb token is a new standup which can be used for
token based authentication.
One of the main differences with other talking based standards is that because of their structure JWT
tokens do not require database validation.
Jason Webb tokens can be easily used in a jungle as free more power.
The rest api using the Django framework simple JWT baggage which can be installed via a peep.
We are not going to see how to implement these specific package but by the end of the course you will
have enough knowledge to be able to integrate it by yourself.
That was it for this lecture.
See you in the next one.
Well we're going to learn how to implement registration and authentication and points in our arrest
API.
Using the Django test of package.