Firebase Authentication: Every Sign-In Method, Explained

Every app with accounts needs to answer one question: *is this person who they say they are?* Firebase Authentication answers it for you, so you never have to store a password yourself.

That last part matters more than it sounds. Storing passwords safely is genuinely hard, and getting it wrong is how companies end up in the news.

What actually happens when someone signs in

Think of it like a nightclub with a bouncer and a wristband.

1. 1

   Someone proves who they are

   They type a password, tap *Sign in with Google*, or enter a code from a text message. This is the bouncer checking ID.

2. 2

   Firebase gives them a wristband

   It is called an ID token — a signed string proving Firebase checked them. Nobody can forge it, because Firebase signs it with a key only Google holds.

3. 3

   The wristband is shown at every door

   Every request your app makes carries that token. Firestore, Storage and your own server can all read it and see who is asking.

4. 4

   The wristband expires

   ID tokens last one hour. The SDK quietly swaps in a fresh one before it runs out, so the user never notices.

The sign-in methods, and when to use each

Most apps should start with Google sign-in plus email/password. It covers nearly everyone, costs nothing, and needs no extra infrastructure.

Anonymous accounts are underused

Anonymous sign-in creates a real account with a real user ID, without asking for anything. The person can use your app immediately, and their data is saved properly.

Later, when they decide to sign up for real, you link the anonymous account to an email or Google account. Same user ID, same data, nothing lost.

This is how you avoid the sign-up wall that makes people leave before they have seen anything.

import { getAuth, signInAnonymously, linkWithCredential, EmailAuthProvider } from "firebase/auth";

const auth = getAuth();

// Day one: let them straight in.
await signInAnonymously(auth);

// Later: same account, now with an email attached.
const credential = EmailAuthProvider.credential(email, password);
await linkWithCredential(auth.currentUser, credential);

Phone authentication, and what it costs

Phone sign-in sends a code by SMS. It feels simple and it is popular, but it is the one method with a real bill attached — every text message costs money, and the price varies by country.

It also attracts abuse. Bots trigger thousands of texts to numbers they control, and you pay for all of them. Firebase applies reCAPTCHA and rate limits, but if you turn phone auth on, set a budget alert the same day.

Authentication is not authorisation

These two words look alike and mean different things. Getting them mixed up is the most consequential mistake in this whole topic.

• Authentication — *who are you?* Firebase Auth answers this.
• Authorisation — *what are you allowed to do?* Firebase Auth does not answer this.

Signing someone in does not protect your data. If your Firestore rules say anyone can read anything, then anyone can — signed in or not. Authorisation lives in your security rules.

rules_version = "2";
service cloud.firestore {
  match /databases/{database}/documents {

    // A user can read and write only their own document.
    match /users/{userId} {
      allow read, write: if request.auth != null
                        && request.auth.uid == userId;
    }
  }
}

request.auth.uid is the wristband being checked at the door. Without a rule like this, authentication is decoration.

Two-factor authentication

Firebase supports a second verification step — usually an SMS code after the password. It is available through Identity Platform, the paid upgrade to Firebase Auth, rather than the free tier.

Identity Platform also adds SAML and OpenID Connect for enterprise logins, and multi-tenancy if you serve several organisations from one project. If none of those words apply to you, the free tier is fine.

Where people go wrong

1. Trusting the client. Anything the app tells your server can be faked. Verify the ID token server-side with the Admin SDK before you believe it.
2. Leaving rules open. Test mode rules let anyone read everything, and they expire after 30 days — often on a weekend, which is how a working app suddenly breaks.
3. Forgetting Apple sign-in. If your iOS app offers Google or Facebook login and not Apple, App Review will reject it.
4. Not verifying emails. Without verification, anyone can sign up as anyone@yourcompany.com.
5. Assuming the user object is fresh. Custom claims and roles are baked into the token when it is issued. Change someone's role and it does not apply until the token refreshes, up to an hour later.