All language subtitles for 005 How Authentication with JWT Works_Downloadly.ir_en

So we have our user model set up

ready to save users with secure passwords.

And so next up, we're gonna really implement

user authentication and authorization.

So in simple terms, the whole work flow

of logging users in and allowing them

to interact with certain protected resources

that non-logged in users cannot access.

Now there are many authentication methods out there,

but the one we're gonna use is a very modern, simple

and secure approach called Json Web Tokens or JWT for short.

So Json Web Tokens are a stateless solution

for authentication.

So there is no need to store any session state on the server

which of course is perfect for restful APIs like the one

that we're building.

Because remember, restful APIs should always be stateless.

And the most widely used alternative to authentication

with JWTs is to just store the user's log-in state

on the server using sessions.

But then of course does not follow the principle

that says that restful APIs should be stateless

and that's why we're opting for a solution like JWTs.

So now let's take a look at how authentication

actually works with Json Web Tokens.

And assuming we already have a registered user

in our database, this is how a user logs into the app.

So the user's client starts by making a post request

with the username or email and the password.

The application then checks if the user exists

and if the password is correct.

And if so, a unique Json Web Token for only

that user is created using a secret string

that is stored on a server.

And a JWT itself is really just a string

that looks something like this.

But we're gonna talk more about the JWT itself

in the next slide.

Anyway, the server then sends that JWT back to the client

which will store it either in a cookie or in local storage.

And just like this the user is authenticated

and basically logged into our application

without leaving any state on the server.

So the server does in fact not know which users

are actually logged in.

But of course, the user knows that he's logged in

because he has a valid Json Web Token which is a bit like

a passport to access protected parts of the application.

So again, just to make sure you got the idea.

A user is logged in as soon as he get back

his unique valid Json Web Token which is not saved anywhere

on the server.

And so this process is therefore completely stateless.

Then, each time a user wants to access a protected route,

like his user profile data, for example,

he sends his Json Web Token along with a request.

So it's a bit like showing his passport to get access

to that route, right?

And that's probably the best and easiest way to understand

this whole idea.

Now once the request hits the server,

our app will then verify if the Json Web Token

is actually valid.

So if the user is really who he says he is.

And more about how this step works

a bit later in this video.

Now if the token is actually valid, well,

then the requested data will be sent to the client

and if not, then there will be an error telling the user

that he's not allowed to access that resource.

And as long as the user is logged in,

this is how it's gonna work each time that he requests data

from any protected route.

Now what's very important to note here

is that all this communication must happen over https.

So secure encrypted http in order to prevent

that anyone can get access to passwords or Json Web Tokens.

Only then we have a really secure system.

But we will talk about that later in the section, okay.

So I know that this can look quite confusing

in the beginning when you first try

to wrap your head around it, but actually

the principle itself is actually quite simple, all right?

And this is really all you need to know in order

to be able to implement authentication using JWT.

But let's now dive a little bit deeper into how

the JWT itself actually works.

So a Json Web Token looks like left part of this screenshot

which was taken from the JWT debugger at jwt.io.

So essentially, it's an encoding string

made up of three parts.

The header, the payload and the signature.

Now the header is just some metadata about the token itself

and the payload is the data that we can encode

into the token, any data really that we want.

So the more data we want to encode here,

the bigger the JWT.

Anyway, these two parts are just plain text

that will get encoded, but not encrypted.

So anyone will be able to decode them and to read them.

So we cannot store any sensitive data in here.

But that's not a problem at all

because in the third part, so in the signature,

is where things really get interesting.

The signature is created using the header, the payload

and the secret that is saved on the server.

Remember that?

And this whole process is then called

signing the Json Web Token.

So again, the signing algorithm takes the header,

the payload and the secret to create a unique signature.

So only this data plus the secret

can create this signature, all right?

Then together with the header and the payload,

these signature forms the JWT,

which then gets sent to the client.

Now as I mentioned briefly, right in the first slide,

once the server receives a JWT to grant access

to a protected route, it needs to verify it

in order to determine if the user really is

who he claims to be, right?

In other words, it will verify if no one changed the header

and the payload data of the token.

So again, this verification step will check

if no third party actually altered either the header

or the payload of the Json Web Token.

So, how does this verification actually work?

Well it is actually quite straightforward.

So once the JWT is received,

the verification will take it's header and payload

and together with the secret that is still saved

on the server, basically create a test signature.

But the original signature that was generated

when the JWT was first created is still in the token, right?

And that's the key for this verification.

Because now all we have to do is to compare

the test signature with the original signature.

And if the test signature is the same

as the original signature, then it means that the payload

and the header have not been modified, right?

Because if they had been modified,

then the test signature would have to be different.

Therefore in this case where there has been no alteration

of the data, we can then authenticate the user.

And of course, if the two signatures

are actually different, well, then it means

that someone tampered with the data.

Usually by trying to change the payload.

But that third party manipulating the payload

does of course not have access to the secret,

so they cannot sign the JWT.

So the original signature will never correspond

to the manipulated data.

And therefore, the verification will always fail

in this case.

And that's the key to making this whole system work.

It's the magic that makes JWT so simple,

but also extremely powerful.

So let me summarize it again.

Without the secret, no one will be able to manipulate

the JWT data because they cannot create

a valid signature for the new data.

I mean they could manipulate the data of course,

but it will always fail the verification step.

Now, don't worry, we're not gonna actually implement

these JWT algorithms by ourself.

They are very complex and we're not gonna

reinvent the wheel here, all right?

But it's still very important to actually understand

how this whole process works behind the scene.

And I hope that this lecture did just that for you.

But now, let's move on to the next lecture

to actually start using all this.