[MUSIC PLAYING]
PETER FRIESE: Building secure applications
is more important than ever.
Users trust apps with the most sensitive information.
And they expect that this data is safe and secure.
But at the same time, the threats are evolving.
And developers need to work hard to fend off attackers.
This is a new series called "Better Safe Than Sorry,"
where we'll dive into how to best protect
your app from malicious actors.
RACHEL MYERS: We'll deep dive into how
different forms of authentication
are more or less secure and what you as the app developer
can do to use them as securely as possible.
In this series, we'll also talk about how to write and to test
your security roles.
And we'll explore how App Check can make sure
that only users on your genuine app
are able to talk to your back end.
PETER FRIESE: Our goal is to demystify
authentication and security.
And to do that, we'll talk to the people who
built the platforms and tools that
keep Firebase safe and secure.
RACHEL MYERS: Here we go.
[SNAP]
PETER FRIESE: Throughout the series,
we'll be working with this app to explain the concept we're
talking about.
It is a To-Do app built on Firebase.
It uses Cloud Firestore to store tasks.
And each user has their own collection of tasks.
It also uses Cloud Storage to store
images associated with tasks like a receipt I
need to pay back to my friend.
And we use Cloud Functions for some backend processing.
Finally, we're using Firebase authentication
to let our users sign in.
RACHEL MYERS: Our application supports multiple client apps--
Android, iOS, and web--
all running on our user's devices.
Our client apps are able to talk directly to the backend.
This is what we call a serverless architecture.
And it gives us a number of major benefits.
For example, there are no servers
that an application developer needs to manage.
Google is doing all of this for us.
Also, and this is really cool, our clients
can receive real-time updates from the backends.
This is what makes the apps feel so snappy.
This architecture might be surprising
if you're used to a server-based architecture, where
the server acts as a natural security gateway
and is the only component of your app
that can talk to the storage layer.
So given that Firebase apps let clients talk directly
to the database, how can a Firebase app
make sure that only users can see their own data?
PETER FRIESE: Well, first of all,
we need to know who the user is and what they're allowed to do.
You may have heard the terms authentication
and authorization.
And it's easy to mix them up.
So knowing who the user is-- that's authentication.
And knowing what they're allowed to do--
that's what we call authorization.
In Firebase, access to every backend service
is protected by one of the following two mechanisms.
The first one is security rules.
And the second one is what we call a trusted environment.
Security rules let you decide who
gets to access data in Cloud Storage and Cloud Firestore.
A trusted environment is a runtime environment
that you or a service provider, like Google, controls.
For example because Cloud Functions
run on Google infrastructure, they're a trusted environment.
On the other hand, because you don't control the user's
device, client applications are not considered a trusted
environment.
Trusted environments can use the Firebase Admin SDK,
which gives them full access to all the information
in your database.
For example, if you write a Cloud Function,
you can access the user's details, such as their user
ID and other information that you control
and use this to decide what they should be allowed to do.
So because Cloud Functions are considered trusted
and have full access, it is your responsibility
to code defensively when using the Admin SDK
inside of Cloud Functions.
We will talk about this in more detail in a future video.
RACHEL MYERS: So when a client sends a request
to the database, for example, to fetch some data,
this request goes through security rules.
Security rules are a configuration file
that you, the application developer,
write to let Firebase know if a request should go through
or be blocked.
For example, to decide if a user should
be able to read a specific document,
you can look at the request to see details about that user.
Each request contains an auth object
that's populated by Firebase authentication
and contains information about the user.
If the user has authenticated, it
will contain a Firebase ID token.
For example, here is a user request
to see all of their to-dos.
The security rules see that this person is only
trying to fetch her own data.
So that request is allowed.
In this example, a user tries to read data
that doesn't belong to her.
And security rules will reject that request.
Preventing access like this is authorization and action.
PETER FRIESE: So let's recap what we've
learned about our app so far.
To access their data, users have to go
through a two-step process, authentication
and authorization.
Authentication is verifying who someone is.
And authorization is checking what they're allowed to do.
For Firestore, Cloud Storage, and Realtime Database,
you can use security rules to handle authorization.
For trusted environments, like Cloud Functions
or your own server, you can handle authorization
by implementing custom logic based
on the user's information.
RACHEL MYERS: Let's dive into authentication.
What does authentication mean?
SCHOLAR TODD: I believe it's from the Latin authenticatus,
meaning original, genuine, or authentic.
RACHEL MYERS: That's right, Scholar Todd.
Authentication of users contains two steps, identification
and a verification process.
First, the user needs to identify themselves.
This is often done by providing a unique identifier
like an email address.
Second, the user needs to prove that they
are who they claim to be.
It could be to provide a secret that only the user would
know, like a password or security question.
Or it could be that they have access
to a device or a key that is registered to that user.
So let's look at a couple of examples.
PETER FRIESE: The most common authentication mechanism
is email and password.
And as you all know, it's hard to make
this form of authentication as secure as possible.
For one, it requires users to pick strong passwords, which
they don't always do.
Also, malicious actors can try to get hold of passwords
by phishing them from the user, or by trying
to get their hands on insecure databases.
RACHEL MYERS: Here's another example.
I'm a fan of signing in via magic links, also known
as email and a sign-in link.
When a user signs up, you can send them
an email that contains a link.
And that has a short-lived, one-time-use authentication
code.
The link takes the user to a login page, where the auth
code is exchanged for a normal, long-lived auth token,
just like someone that signed in with email and password.
This mechanism gets rid of passwords altogether.
So it's an improvement over users and developers
juggling passwords.
And this process automatically verifies your email address.
PETER FRIESE: Phone number authentication
works nearly the same way.
Instead of sending a magic link to an email address,
the authentication code will be sent
to the user's phone via SMS.
In native apps, it's possible to use silent notifications
to receive those authentication codes, which
means the user doesn't even have to switch to their messaging
app to retrieve the code.
RACHEL MYERS: And the last one we want to touch on
is social login, also known as Federated Identity Providers,
or OAuth 2.0 providers.
Instead of creating a separate login for each app, users sign
in to an identity provider, such as sign in with Apple or Google
Sign In.
When a user wants to log in, the application
sends the user to the login page of the identity provider.
And the user logs in there.
Then they're redirected back to the application,
along with the provider token that says,
yes, this is a valid user, and they have successfully
signed it.
And then the app will log them in.
The Federated Identity Providers use
a common standard called OpenID Connect,
or OIDC for short, which is based on OAuth 2.0, which
is an industry standard for authentication Firebase
authentication supports all these forms of auth, email
and password, email and link, phone number auth,
and lots of OAuth 2.0 providers like Google, Facebook, Apple,
and GitHub.
PETER FRIESE: And if you already have your own authentication
system, you can use custom authentication
to integrate your own system with Firebase.
To learn more about this, check out
the documentation at this URL.
RACHEL MYERS: The last piece of authentication
we want to cover in this quick intro
is that in addition to the SDKs, Firebase also
maintains libraries to handle a lot of the tricky parts
of authentication, like password recovery and email
verification.
We've also linked to those libraries in the description.
They're the easiest way to make sure
that you're handling these complicated flows correctly.
PETER FRIESE: OK, so now that we know how authentication works,
let's talk about authorization.
RACHEL MYERS: As a reminder, authentication
is who someone is, while authorization is about what
they're allowed to do.
SCHOLAR TODD: Ah, authorization is
derived from the Latin auctor, and means
to give authority or legal power to.
PETER FRIESE: Thanks, Todd.
Cool.
So after a user has successfully signed in,
their ID token and sent along with every single request
they make to one of Firebase's services,
such as Cloud Functions, Firestore, Realtime Database,
or Cloud Storage.
This is handled automatically by the respective client
SDK, which sends the token as a bearer token.
Bearer token means give access to the bearer of this token.
Usually, those kinds of tokens are sent in the authorization
header of a HTTP request.
Now, if you worry that a malicious actor might intercept
the token, rest assured that firstly, all Firebase SDKs use
HTTPS or other forms of secure communication with the backend.
And secondly, that the ID token is cryptographically signed,
so it will be invalid if it's been tampered with.
But that's not all that's required.
All requests also need to make it through security rules.
RACHEL MYERS: Let's take a look at some basic security rules.
These are taken from our sample To-Do app.
For all documents in To-Do's collection,
the first rule means that anyone who's signed in
can create a new document as long as the user
ID attribute on that document is the same as their user ID.
In other words, they can only create To-Dos for themselves.
The next line says that when reading or modifying
a document, the User ID field on the document
must equal the User ID attribute on the request.
That means users can only read, modify, or delete
their own tasks.
PETER FRIESE: Cool.
So security rules are pretty flexible, but also very
powerful.
And that's why we will spend the entire next episode on security
rules to talk about this in much more detail.
RACHEL MYERS: Good authentication
and authorization is an important defense
against malicious actors trying to impersonate
your legitimate users.
But that's not the only attack vector to watch out for.
PETER FRIESE: Other approaches an attacker might take
are hitting your backends to see if they can get access
to any unprotected information, or running up your bill
by hitting your backends.
To defend against these kinds of attacks,
we have launched a new product called App Check.
App Check is an additional layer of security
that protects access to your services
by attesting that incoming traffic is coming
from your genuine application.
It will block any traffic that doesn't have valid credentials.
This is one more tool to keep your users
and their data safe and secure.
We will talk about this in more detail in the future video.
RACHEL MYERS: That was a lot to take in.
Let's recap everything we've learned.
Firebase authentication lets you identify your users
and provide them with a personalized
experience in your app.
Firebase authentication and security rules together
allow you to implement authorization for your app
and make sure users can only access the data
that you want them to.
And finally, App Check protects your app
from malicious actors having any access to your backends.
PETER FRIESE: In the upcoming episodes,
we will dive deeper into the individual topics,
such as security rules, onboarding and UX,
using the Auth Emulator, and of course, all the authentication
providers that Firebase supports.
If you have any questions, leave us a comment below
or reach out to us on Twitter.
Thanks for watching.
and we will see you in the next one.
[MUSIC PLAYING]