Original subtitles

Now, to understand how authentication works,

it is important to really understand

why we need authentication in the first place.

And the answer here is that we need authentication

in a website because some content should be protected.

Not all users and visitors of our website

should be able to access all content.

That's why we have authentication in place.

Now, content can be different things.

Sometimes you have pages on your site

that should be locked if users

are not authenticated.

For example, throughout this course section,

we are going to work on this demo website here

and there we have this dummy starting page.

Then we have this login page

where we can also create new users

and we have this profile page

where users can change their password.

And for example, this page, this profile page

should only be accessible to users

who are logged in.

And if you are not logged in,

you should not be able to visit this page.

So this kind of content might be locked.

This page should maybe not be accessible

to non-logged in users.

But it's not just pages like this.

Protected content could also be some data

that you're storing in a database,

some API endpoints to which your React application

might be sending requests on certain pages

that should be locked for non-authenticated users,

and there are many examples you could come up with

but back on this page,

on this profile page,

it would be this Change Password request,

which we are sending when this button is clicked.

I mean, at the moment, nothing happens here.

We're going to build this together

but of course, when that button is clicked,

it would be a realistic expectation

that some request is sent to some server

to update this user's password in the database.

And even though we wanna lock down

this profile page entirely,

we also might want to lock down that API endpoint

to which we're sending this request

so that a request sent to this API endpoint can't succeed

if the user is not logged in

because if the API endpoint would not be locked down,

that would mean that any user

who knows the URL of that endpoint

could send a request to change the password

of some other user and that would be very insecure.

So that's why we might not just want

to restrict pages on our websites,

but also API endpoints

to which we send requests from inside our React app.

So that's why we need authentication.

And that brings up another question.

How does authentication then work in general?

And here the answer is quite straightforward.

In general, authentication is a two-step process.

The first step is always to get access,

to get the permission for this user.

And you get that access, that permission

by providing your credentials by logging in.

Of course, you, first of all, need to create an account

but once you've got that,

you do log in with your credentials,

this data is then sent to some server

where we can look into a database

and verify your password and email combination

and if that is valid,

the server, the backend to which the request is sent

grants this permission.

Then once we have this permission,

we can unlock certain pages on the website

and/or, depending on what we need to do,

use that permission to send subsequent requests

to other protected resources on an API endpoint.

So we first get that permission

and then we can send more requests

to other endpoints with that permission attached.

And that's indeed, how that generally works.

We have our client with the React app running in the browser

and some backend server

with some server-side code written by us

or written by someone else.

It can be a third-party API,

an external API with which we're working here

or it can be our own API.

And then we, first of all, send that request

with the email, password combination,

the server then verifies that,

checks our credentials

and then either grants permission

for further requests or denies that.

And then we can use that permission

as I described it a couple of seconds ago.

But is that enough

if we just get this permission

and we then can use this permission

for subsequent requests?

Well, it's not enough.

A yes or no alone is not enough

to then access protected resources like API endpoints.

And it's not enough because a yes or no

is easy to fake.

If the server to which we send our credentials

would just reply with a yes or no,

we could just skip that step

of getting the permission and just instead add our own yes

or no to requests for protected resources.

So that's why this is not enough

and why authentication is a bit more elaborate than that.

That part with sending and checking the credentials

all needs to happen but the response sent back

by the server to the client must be more

than just a yes or no.

And here we've got two main approaches,

which are commonly used.

We can either work with server-side sessions

or with authentication tokens.

Now, server-side sessions

are a very traditional approach of handling authentication

and they are a great approach of handling authentication.

With server-side sessions,

once a server grants you access,

that server stores a unique identifier

for your client, so for this specific user

who was just granted access.

The server generates and stores some unique identifier

for this specific client

and therefore, every visitor of a website

who authenticates gets his or her own identifier stored

on the server.

But this identifier is not just stored on the server,

it's also sent back to the client.

So the response of the server

is not just this yes or no

but instead, it does now also

include this unique identifier.

So the server and the client,

both parties know this identifier.

And then it's this identifier,

which is attached to future requests to this server

and since the server knows this identifier,

this identifier can't be faked.

If you come up with your own random identifier,

the server won't know it

and access will be denied for this subsequent request.

So that's a great mechanism.

But this mechanism has one disadvantage.

It works great if your backend, your server

and your front end are tightly coupled

but if you've got decoupled ends,

if you've got your Single Page Application served

by server A and you've got your backend application,

your REST API served by server B,

then there is no tight coupling.

The backend API probably should work independent

from the front-end Single Page Application

and vice versa.

Or if you are building an API

that is there to be used by many websites,

think about something like the Google Maps API,

then, of course, this API also can't be tightly coupled

and focused on one specific front end.

Instead it needs to stay flexible.

And that's why then you don't wanna store some identifier

on the server.

The server should be stateless, as it's called.

The server should not store this kind of data

about the connected clients.

There is a decoupled backend and front-end situation.

And you will very often have to deal with that

when building Single Page Applications

and that's therefore, the part I wanna focus on

in this module

because in this situation,

you can use authentication tokens

because the idea here is generally is the same.

There is just one key difference.

The general idea still is that you send some credentials,

email and password to a server

and the server validates those credentials

by comparing your email password combination

to what's stored in the database.

Then if that's valid,

the server creates a permission token,

which is basically just a very long string

with some data encoded into that string.

The server will basically use some algorithm

to encode some data, like the email address

of the user and a bunch of other pieces of data

into one string,

which can be decoded back

into these individual pieces of data.

It's really just a way of gluing different pieces

of data together.

Now, this token will be generated by the server

with a specific algorithm and very important,

with a key, which will be used for hashing that data

into a string,

which is only known by the server.

So there is a key involved,

which is only known by the server, not by the client.

Now, this token is not stored by the server

but sent back to the client

but only the server knows how to create that token

because of that key which is involved.

Now, therefore, the client can then use this token,

so the React app is able to use that token

to attach it to future requests

to protected resources on the server.

And even though the server hasn't stored this identifier,

as it did in the session approach,

the server is able to verify

that this token was created by it

because only the server knows this private key,

which was involved in the token creation process

and therefore, the incoming token,

which is attached to the request

for some protected resource

can be validated by the server

because the server is able to check if that token

could have been created by it, by the server.

And if the token was faked or created

with a different key,

then the server will detect this and will deny access.

So this is then another secure way

of identifying a client to the server.

And this is an approach that allows for decoupling

of front-end and backend

and it's therefore, the approach we're going to use

in this course module.