[Maximilian Schwarzmuller] So we got
that user signup implemented, but as mentioned,
that isn't really the authentication process yet.
Instead, we want to make sure that users, for example,
can't visit /training if they didn't just log in,
so if they're not authorized.
And therefore we need to answer one important question,
how exactly does authentication work?
What do we have to do as a next step?
Well, in the end, authentication is a two part process,
and the first part is that we must be able to log users in,
which in the end means that we wanna be able to verify
user credentials, email and password,
check if they're valid,
if they match the ones that were used
during account creation and,
and that's very important,
we want to then mark a user
who did provide valid credentials as authenticated.
We need some way of remembering
that this user who just sent this request is authenticated
and should be granted access to protected resources,
because that's the second part,
that we have certain resources that should be protected
and that should only be made accessible
to authenticated users, to users who logged in
and who are marked as authenticated.
Now let's start with that first part,
logging users in and marking them as authenticated.
It all starts with a client, a user visiting our website,
who in the end sends a request to our server,
a request where they filled out that authentication form
to either create a new user
or to log in with an existing user
and either way, they send some credentials
along with that request, because they submitted that form.
So they sent an email and a password to the server.
On that server, we then verify those credentials,
either because we just create a new user
and we check whether we have a valid email,
a valid password and the user doesn't exist yet
or because the user tried to log in,
we take a look at the existing users
that we stored in the database
and we check
whether that email password combination
that was submitted is valid.
If we consider it valid, so if we determine
that the user did provide correct credentials,
we create a so-called authentication session,
which in the end is simply a database entry
that's stored in a dedicated table on the server,
that's how we remember
that a certain user is now considered to be authenticated,
we store a new entry in a table.
Now that entry, in a table,
will in the end have an ID, a so-called session ID,
and we then send back that ID,
typically in a cookie, to the user.
So the response to that authentication request,
to that login request,
contains such, a session cookie,
a cookie with such a session ID,
if the credentials were valid
and the client, the browser, will then automatically store
that session cookie, that's the first part.
Now that we have this cookie,
and now that we remembered on the server
that this user is considered to be authenticated,
we can move on to the second part,
which is about accessing protected resources.
Because let's now say a user who just logged in
and who has that cookie now sends a request
to some route that should be protected
and we'll write some code that will protect the route,
and you will see how that works in that section.
What's important about that request
is that the browser will automatically add cookies
that belong to our website to those requests,
so that session cookie will automatically be attached
to that request and will be sent to the server.
On the server, we can then take a look
at that session cookie and verify its validity.
So if it in the end contains a session ID,
we also have in our database, if it's a valid session id.
And therefore those session IDs
also aren't just some kind of numbers,
but instead more complex strings
that can't be easily made up.
Now, once we determined that we got a request
with a valid active session cookie,
we sent back the requested resource.
So for example, the page content the user wanted to see,
or if the cookie doesn't look all right,
if the session expired or something like that,
we send back an error,
that's in the end how authentication works
and that's what we'll now implement over the next lectures.