In this lecture, we're going to discuss how authentication works, the next step for an application
is to authenticate the user after they've registered an account.
This step is entirely optional.
It completely depends on the needs of your project.
However, you'll find that most apps will log you in after creating an account.
It's a common user experience.
We're going to implement this experience for our users before we get into writing code.
Let's understand how authentication works behind the scenes.
First thing's first, we have to use our project as two different applications.
We have the angular application we're building and then we have Firebase authentication is mainly handled
on the server.
In our case, this would be Firebase.
Firebase can take care of hashing passwords, sending a confirmation email or storing the user's data.
As for front end developers, we don't have to worry about these kinds of things.
The role of the front end is relatively simple.
We send the log in data to the server.
The server responds with a token and then we store that token.
There's not much else for us to do.
Authentication tends to be the same across many backend solutions, even though we're using Firebase
as our server.
You can apply this process to almost any backend, regardless if it's PHP node or some other programming
language.
Let's break down the authentication process step by step.
Our angular application will send the user's login data to Firebase.
We're familiar with this step.
We performed it at the start of this section.
Firebase will take care of authenticating the user.
It'll check if a user exists with the credentials we sent over.
If the authentication is successful, Firebase will generate a token.
The token is what's sent back as the response tokens typically come in the form of a unique stream.
Storage of the token is essential.
There are various methods at our disposal under the hood.
Firebase uses extended DB.
It's an API for storing structured data on the user's browsers.
This API is shipped with browsers.
We don't need to enable this feature to start using it.
It works out of the box.
After storing the token, we can send it to Firebase with our requests.
Firebase will verify the user by checking the token.
This process happens automatically whenever we send a token.
Since tokens are unique, we don't have to worry about a user's data being manipulated without their
permission.
We don't need to rescind the authentication info again.
The token will suffice.
This is just an overview of how things work.
I'll get into specifics later in this section.
It may seem like a lot to do, but it's rather simple and easy to implement.
Once you see how it's done, the overall process I'm talking about is called stateless authentication.
You may have heard of this term before.
If not, that's fine.
Let's talk about it.
Traditionally, applications kept track of users by using a feature called Sessions.
Sessions are stored on the server.
The server actively knows who is logged in when the server keeps track of authenticated users.
This is what's called stateful authentication.
However, in our case, Firebase will not keep track of who's logged in.
Instead, we're going to use tokens to verify the user for every request we send.
We will also send the token.
Firebase will use the token to confirm that the user is who they say they are because the server doesn't
keep track of who's logged in.
This is what's called stateless authentication.
It's very common to implement stateless authentication for single page applications.
While sessions are still practical, it's much easier to work with tokens.