Next up we are going to cover authentication professionally explained.
Authentication is verifying if you are who you say you are in everyday terms or everyday features that
probably every single one of us has used at least once.
This is the possibilities to have a user account to sign in to that account by using email password
combination.
By having a Remember Me feature that lets you stay signed in for longer periods of time, typically
in weeks, and then being able to create an account by submitting a form.
Now how are we going to achieve that?
We will have to create different modules and different parts of the system.
So I've listed four main building blocks of the authentication system that we are going to create.
So let me start from the second one because controllers is something we already understand.
So we're going to create an authentication controller which would have a couple of functionalities.
One would display a login form.
Another action will handle the form submission where someone would send the username and password.
And also we need an action to log out.
Then we need a view that will display the HTML form.
And inside our user model we need to add functionality to find the user by email.
Then we've got a new type of classes called services.
So what is a service?
Well, there is no specific description of what a service class is, but if I would be to explain that,
I would say that this is the most generic name or namespace for a class that contains some bespoke business
logic.
So in our current scenario, this might be getting the currently authenticated user model.
So this means service classes are classes that can touch different fields.
So getting currently authenticated user model might mean that there needs to be a method that will both
use the sessions, then would be able to fetch something from the database.
So generally it means having a logic that might just use different parts of our system, of our existing
system.
So the features that we're going to put in this class is, as I've said, getting the current user model,
then trying to authenticate the user by verifying the username and password, and then also storing
the user ID in the session and logging out.
Because every single one of those four features contains a couple of steps, and it interacts with different
domains of our app like sessions, cookies, databases, etc..
And here is the typical flow of how the authentication looks like from the very first screen, where
you see the login form until you log out.
So I would try to explain this simply.
So we always need to start with some way of letting the users verify that they are who they say they
are, and we do that using a login form.
We present the user with two fields the username and password.
Username is often the email, and when this form is submitted, we need to verify user credentials.
How do we do that?
First, we are trying to fetch a user by the specified email or the username.
So we can compare this process to bank employed at some kind of company.
First, to be able to enter you need to be an employee.
So that's the first process checking if you are even employed.
But then you would have to present a valid badge that can be scanned by security.
So they let you in because you can always claim that you are an employee.
But maybe unfortunately you were fired and you no longer have the badge, which is the password, and
you shouldn't be let in.
Same with authentication.
So the next step would be to compare the password hash.
What does that mean.
So it stems from the fact that you don't store passwords in plain text inside the database.
At least you should never do that.
In plain words, this means that let's say my password is just password one two, three.
I would not store this as this string inside the database column.
Instead, I would first make this password go through a process called hashing, which converts the
plaintext password into a hash, which is just a collection of randomly generated strings and the hashing
algorithms for the same input.
They always provide the same output, but if you see a hash, there is very little chance that you would
be able to figure out the password.
Now, the way this process works is that you store a hashed password.
Thus you also give some extra security to your users because if someone breaks in to the database,
he won't know all the passwords.
And additionally, you don't know the passwords of your users, which might give them more safety and
they might trust you more.
I say we compare the password hash because what we do is we compare what the user has entered, we generate
a hash of it, and then we compare that with a hash that we have stored inside the database.
This sounds complicated, but in PHP this is just a single function call.
Because PHP comes with a function that can verify hashed passwords, and also with another one that
can hash a text.
So if the hash that was generated from the user input matches with the hash stored inside the database
in the user's table password column, the next step is to store this user ID inside the current session.
And then whenever we need to retrieve the currently authenticated user, we just look up the session.
If there is the user ID and we fetch the user by ID from the database.
This is how the user can stay authenticated because we store his user ID in his session that will anyway
automatically expire after some time.
So this gives us extra safety that the user would be logged out after certain time of inactivity, but
additionally, he should have an option to log out explicitly manually, and this would involve clearing
the user ID from the session or even regenerating the session.
So this is more or less how the authentication process looks like.
Now there is obviously more to it, and we are going to talk about the details once we work with the
specific parts of this process.
For now, let's just begin building this authentication system for the current project.