All language subtitles for 009 Understanding Authentication_en

In this lecture, we're going to discuss how authentication works.

The next step for our application is to authenticate the user after they've registered an account.

This step is entirely optional.

It entirely 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 that, let's understand how authentication works behind the scenes.

First things first we have to view our project as two different applications.

We have the view application we're building and then we have Firebase Authentication is mostly handled

on the server.

In our case, this would be Firebase.

Firebase can take care of hashing the password, sending a confirmation email or storing the user's

data.

As frontend developers, we don't have to worry about these kinds of things.

The role of the front end is relatively simple.

We send the login 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 back end solutions.

Even though we're using Firebase as our server, you can apply this process to almost any back end,

regardless if it's a PHP node or some other programming language.

Let's break down the authentication process.

Step by step.

The Vue application will send the user's login data to Firebase.

We're already 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 string.

It's essential we store this token.

There are various methods at our disposal.

The method will be going with is local storage.

Local storage is a web API that comes with your browser by default.

It's not specific to view.

Once we've stored the token, we can send it to Firebase whenever we want to store or update data related

to the currently authenticated user, the token will be used to verify the user.

Since tokens are unique, we won't have to worry about a user's data being manipulated without their

permission.

We don't need to resend 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 before.

If not, that's fine.

In the case of traditional applications, something called sessions is used to keep track of who's logged

in.

Sessions are stored on the server.

The server actually knows who was logged in when the server keeps track of this.

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.

The token will be used by Firebase 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.

We'll need to make a minor modification to the security rules before we move forward.

Currently, I'm in the rules section for the Firestone database.

Pause the video if you need to navigate to this page.

As it stands, anyone is allowed to interact with the database.

They can even delete the entire database if they wish.

We don't need to keep the same rules anymore.

It's dangerous to allow anyone to have this much power we want to restrict who can read and write to

the database nested deeply inside the rules.

The same condition is being used for read and write permissions.

We'll want to have different conditions for reading and writing.

For reading.

We'll allow anyone to view the data for writing will restrict permissions to authenticated users only

we'll empty out the block completely.

Add the following allow read if true.

Allow write if request off uuid exclamation point equals null.

The first line will allow anyone to read the database.

We aren't going to store sensitive data such as passwords.

It's all right if the data is accessible.

As for the writing permission, we're using an object called request.

Firebase will define this object for you.

We don't have to do anything to receive it.

We can use it to learn more about the user who's trying to access the database.

If we have the authentication service turned on, we'll be able to access information about the user

who's currently logged in in the resource section of this lecture.

I provide a link to the authentication object.

According to the documentation, every authentication object will come with a UID and token property.

The one we're using is called UID.

If the user is not authenticated, this will be set to null.

Back on the rules page.

We're checking if the UID property is not equal to null.

If this condition returns true, then the user will be able to write to the database.

Otherwise they'll be denied access.

We're going to publish the rules before doing so.

Make sure your rules match mine.

We're finished with modifying the rules.

In the next lecture, we'll begin authenticating the user into the application.