Firebase Authentication: 9 Types Explained – What, Why, When and Where to Use Each (Easy Guide)

Every time you type an OTP in a shopping app, tap “Continue with Google”, or enter a password on a website, you are going through authentication. It is the first door of almost every app, and if that door is weak, nothing behind it is safe.

In this guide I will explain authentication in simple words, and then show you Firebase Authentication, Google’s ready-made login service that works with Android, iOS, web and Google Cloud. You will learn what it is, why we use it, the 9 types of Firebase Authentication, when to use which type, where to use it in your app, and how to set it up with code you can copy and paste.

Last reviewed: November 2026

In this guide:

• What is authentication?
• Authentication vs authorization
• What is Firebase Authentication?
• Why we use authentication
• How Firebase Authentication works
• 9 types of Firebase Authentication
• When to use which type
• Where to use authentication
• How to use Firebase Authentication step by step
• Pricing
• FAQs

What Is Authentication?

Authentication is the process of proving who you are. When an app asks “Are you really Rahul?”, authentication is how you answer.

Think of a bank branch. Before the cashier gives you money, they check your passbook, signature or Aadhaar-linked OTP. The cashier is not deciding how much you can withdraw yet. They are only confirming that you are the real account holder. That check is authentication.

Apps prove identity using one or more of these “factors”:

Factor	Meaning	Example
Something you know	A secret only you should know	Password, PIN
Something you have	A device or account you own	Phone receiving OTP, Google account, authenticator app
Something you are	Your body	Fingerprint, face unlock

Using two different factors together is called multi-factor authentication (MFA), like a password plus an OTP. It is much harder to break than a password alone.

Authentication vs Authorization

These two words sound similar, and many beginners mix them up. Here is the simple difference:

Point	Authentication	Authorization
Question	Who are you?	What are you allowed to do?
Happens	First	After authentication
Example	Logging in with OTP	Only admins can delete products
In Firebase	Firebase Authentication	Security Rules, custom claims, IAM

A hotel is a good picture of this. Showing your ID at reception is authentication. The key card that opens only room 304, and not the manager’s office, is authorization.

What Is Firebase Authentication?

Firebase Authentication is a managed sign-in service from Google. It gives you ready SDKs for Android, iOS, web, Flutter and Unity, a backend that stores user accounts safely, and built-in support for email, phone OTP, Google, Apple and many other login methods.

Without it, you would have to build and secure all of this yourself:

• A users table with safely hashed passwords
• Password reset and email verification emails
• OTP sending, expiry and retry limits
• Login with Google, Apple and Facebook using OAuth
• Secure session tokens that expire and refresh
• Protection against brute-force and bot sign-ups

Firebase Authentication does all of this for you, and every signed-in user gets a unique UID that you can use across Firestore, Cloud Storage, Cloud Functions and your own APIs.

There is also an optional upgrade called Firebase Authentication with Identity Platform. It adds enterprise features like multi-factor authentication, SAML and OpenID Connect login, blocking functions and multi-tenancy.

Why We Use Authentication

• To protect private data: Your chats, orders, photos and payments should be visible only to you.
• To personalise the app: Your cart, watch history and saved addresses follow you to any phone.
• To control access: Admins, sellers and customers can see different screens and data.
• To build trust: Verified phone numbers and emails reduce fake profiles in dating, matrimonial and marketplace apps.
• To stop abuse: Limits like “one coupon per user” only work when you know who the user is.
• To meet legal and audit needs: Finance, health and business apps must record who did what.

Why Use Firebase Authentication Instead of Building Your Own?

• Security by Google: Password hashing, token signing and account protection are handled by a team that does this full time.
• Faster launch: A working login screen takes hours, not weeks.
• Many providers, one user: A user can link Google, phone and email to the same account and keep one UID.
• Works with Security Rules: Firestore and Storage rules can read request.auth.uid directly.
• Generous free usage: Email, social and anonymous sign-in cost nothing for most small and medium apps.

How Firebase Authentication Works

1. The user chooses a login method, such as phone OTP or Google.
2. The Firebase SDK talks to that provider and confirms the user’s identity.
3. Firebase creates (or finds) the user account and returns a signed ID token. This token proves who the user is and is valid for one hour.
4. The SDK refreshes the token automatically in the background, so the user stays signed in.
5. Every request to Firestore, Storage or Functions carries the token, and your rules or server code read the user’s UID from it.

You never handle passwords or OTPs on your own server. That alone removes a big class of security bugs.

9 Types of Firebase Authentication

Firebase Authentication supports many sign-in methods. I have grouped them into 9 practical types. For each one you will see what it is, when it fits, and its main drawback.

1. Email and Password Authentication

The classic login. The user signs up with an email address and a password, and Firebase stores the password securely. Firebase can also send verification and password reset emails for you.

• Use it when: Your users are comfortable with email, such as office tools, B2B apps, blogs and admin panels.
• Drawback: People forget passwords and reuse weak ones. Always turn on email verification.

2. Email Link (Passwordless) Authentication

The user enters only an email address. Firebase sends a magic link, and tapping it signs them in. No password to remember.

• Use it when: You want simple, secure login for web apps, newsletters, event registrations or occasional-use tools.
• Drawback: The user must switch to their inbox, and emails sometimes land in spam.

3. Phone Number (OTP) Authentication

The user enters a mobile number and receives a one-time code by SMS. On many Android phones the code is read automatically.

• Use it when: Your audience is mobile-first, as in India, where people trust OTP login for shopping, delivery, matrimonial and payment apps.
• Drawback: Every SMS costs money, and SMS can be targeted by fraud like SIM swap. Use it with App Check and sensible limits.

4. Google Sign-In

One tap with the Google account already on the phone. No password, no OTP, and the email is already verified by Google.

• Use it when: You have an Android app or a web app. It is the fastest, cheapest and most popular option for most apps.
• Drawback: Some users do not want to share their Google identity, so offer a second option too.

5. Sign in with Apple

Login with an Apple ID, using Face ID or Touch ID. Users can even hide their real email behind an Apple relay address.

• Use it when: You publish on the iPhone App Store. If your iOS app offers other third-party logins like Google, Apple’s review guidelines generally expect an equivalent privacy-friendly option such as Sign in with Apple.
• Drawback: Setup needs an Apple Developer account and some configuration.

6. Other Social Logins (Facebook, Microsoft, GitHub, X, Yahoo)

Firebase also supports Facebook, Microsoft, GitHub, X (Twitter) and Yahoo sign-in. These are called federated logins, because another company confirms the user’s identity.

• Use it when: Your audience already lives on that platform. GitHub suits developer tools, Microsoft suits office and school users, Facebook suits social and gaming apps.
• Drawback: Each provider needs its own developer app setup, and too many buttons confuse users. Pick two or three.

7. Anonymous Authentication

Firebase creates a temporary account with a real UID, but without asking for any details. Later, the user can “upgrade” by linking Google, phone or email, and all their data stays with them.

• Use it when: You want users to try the app first, such as a guest cart in e-commerce, games, quiz apps or onboarding screens.
• Drawback: If the user uninstalls before linking an account, that data is lost. Old anonymous accounts also pile up, so clean them regularly.

8. Custom Authentication (Custom Tokens)

You already have a login system, such as a company database, a school ERP or a legacy SQL users table. Your server checks the user, then creates a Firebase custom token with the Admin SDK, and the app signs in with that token.

• Use it when: You are moving an existing app to Firebase, or users log in with an employee ID, student roll number or another system Firebase does not support directly.
• Drawback: You must run and secure your own server for the first check.

9. Enterprise Login: SAML and OpenID Connect (OIDC)

Large companies use identity systems like Okta, Azure AD (Microsoft Entra ID) or Google Workspace. With the Identity Platform upgrade, Firebase Authentication can accept these logins through the SAML or OIDC standards, so employees use their office account.

• Use it when: You sell a B2B SaaS product or build internal tools for companies that require “single sign-on (SSO)”.
• Drawback: It needs the Identity Platform upgrade, and SAML/OIDC users are billed after a small free tier.

Bonus: Multi-Factor Authentication (MFA)

MFA is not a separate login type. It is an extra layer on top of email and password: after the password, the user also enters an SMS code or a code from an authenticator app (TOTP). Firebase supports this through the Identity Platform upgrade. Use it for fintech, admin panels, healthcare and any account that controls money or sensitive data.

When to Use Which Type of Firebase Authentication

Here is a quick comparison of all 9 types:

Type	User effort	Cost	Security	Best for
Email + password	Medium	Free	Medium (high with MFA)	B2B, admin panels, web apps
Email link	Low	Free	Good	Web apps, occasional users
Phone OTP	Low	Paid per SMS	Good	Indian consumer apps, delivery, matrimonial
Google	Very low	Free	High	Most Android and web apps
Apple	Very low	Free	High	iPhone apps
Other social	Very low	Free	High	Developer, social and office apps
Anonymous	None	Free	Low (temporary)	Guest mode, games, try-before-signup
Custom token	Depends	Free (your server costs)	Depends on your system	Migrations, ERP or legacy logins
SAML / OIDC	Very low	Paid after free tier	Very high	Enterprise SSO, B2B SaaS

Which Authentication to Choose for Your App Type

App type	Recommended combination	Why
E-commerce / food delivery	Anonymous (guest cart) → Phone OTP + Google	Users browse first, then sign in quickly at checkout
Matrimonial / dating	Phone OTP + Google	Verified phone numbers reduce fake profiles
EdTech / online courses	Google + Email and password	Students and parents mostly have Gmail; schools may need email
Fintech / payments	Phone OTP + MFA	Money needs a second factor and strong verification
Mobile games	Anonymous → link Google or Apple later	Zero-friction start, progress saved after linking
B2B SaaS / company tools	SAML / OIDC + Email and password with MFA	Companies want SSO and strict security
Internal admin panel	Google (company accounts) + custom claims	Easy login, admin role checked in rules
Existing app moving to Firebase	Custom tokens, then add Google	Keeps old users working without re-registration

My simple rule: Start with Google Sign-In plus one fallback (phone OTP in India, email elsewhere). Add anonymous login if users should explore before signing up. Add MFA when money or sensitive data is involved.

Where to Use Authentication in Your App

Signing in is only half the job. Firebase Authentication is useful only when every part of your backend checks the user. Use it in these places:

Where	How authentication is used
Login and sign-up screens	Firebase SDK signs the user in and keeps the session
Firestore and Realtime Database	Security Rules check request.auth.uid before every read and write
Cloud Storage	Rules let users upload only to their own folder, like profile photos
Cloud Functions (callable)	request.auth tells the function which user called it
Your own API on Cloud Run	The server verifies the ID token with the Admin SDK
Admin and role-based screens	Custom claims like admin: true unlock extra features
Analytics and personalisation	The UID links behaviour, preferences and history to one user

Pair it with Firebase App Check. Authentication tells you who the user is, while App Check confirms the request came from your genuine app.

How to Use Firebase Authentication Step by Step

I will use an Android app in Kotlin, since that is the most common case. The same ideas apply to Flutter, iOS and web.

Step 1: Enable Sign-In Providers

1. Open the Firebase console and select your project.
2. Go to Build → Authentication and click Get started.
3. Open the Sign-in method tab.
4. Enable Email/Password, Google, Phone and Anonymous as needed, and click Save for each.
5. For Google and Phone on Android, open Project settings → Your apps and add your app’s SHA-1 and SHA-256 fingerprints (debug, upload and Play app signing keys). Then download the new google-services.json.

Step 2: Add the Libraries

In app/build.gradle.kts, add Firebase Auth and the Credential Manager libraries for Google Sign-In. Replace each LATEST_VERSION with the current version from the Firebase release notes and the Credential Manager release page:

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:LATEST_VERSION"))
    implementation("com.google.firebase:firebase-auth")

    // Google Sign-In with Credential Manager
    implementation("androidx.credentials:credentials:LATEST_VERSION")
    implementation("androidx.credentials:credentials-play-services-auth:LATEST_VERSION")
    implementation("com.google.android.libraries.identity.googleid:googleid:LATEST_VERSION")
}

Step 3: Email and Password Sign-Up and Login

import com.google.firebase.Firebase
import com.google.firebase.auth.auth

private val auth = Firebase.auth

fun signUp(email: String, password: String) {
    auth.createUserWithEmailAndPassword(email, password)
        .addOnSuccessListener { result ->
            result.user?.sendEmailVerification()
            showMessage("Account created. Please verify your email.")
        }
        .addOnFailureListener { e -> showMessage(e.localizedMessage ?: "Sign-up failed") }
}

fun signIn(email: String, password: String) {
    auth.signInWithEmailAndPassword(email, password)
        .addOnSuccessListener { openHomeScreen() }
        .addOnFailureListener { showMessage("Wrong email or password") }
}

fun resetPassword(email: String) {
    auth.sendPasswordResetEmail(email)
        .addOnSuccessListener { showMessage("Reset link sent to $email") }
}

Step 4: Google Sign-In

This uses Android’s Credential Manager, the current recommended way. The default_web_client_id string is created automatically from your google-services.json.

import androidx.credentials.CredentialManager
import androidx.credentials.CustomCredential
import androidx.credentials.GetCredentialRequest
import androidx.lifecycle.lifecycleScope
import com.google.android.libraries.identity.googleid.GetGoogleIdOption
import com.google.android.libraries.identity.googleid.GoogleIdTokenCredential
import com.google.firebase.Firebase
import com.google.firebase.auth.GoogleAuthProvider
import com.google.firebase.auth.auth
import kotlinx.coroutines.launch

private fun signInWithGoogle() {
    val googleIdOption = GetGoogleIdOption.Builder()
        .setFilterByAuthorizedAccounts(false)
        .setServerClientId(getString(R.string.default_web_client_id))
        .build()

    val request = GetCredentialRequest.Builder()
        .addCredentialOption(googleIdOption)
        .build()

    lifecycleScope.launch {
        try {
            val result = CredentialManager.create(this@LoginActivity)
                .getCredential(this@LoginActivity, request)
            val credential = result.credential

            if (credential is CustomCredential &&
                credential.type == GoogleIdTokenCredential.TYPE_GOOGLE_ID_TOKEN_CREDENTIAL
            ) {
                val idToken = GoogleIdTokenCredential.createFrom(credential.data).idToken
                val firebaseCredential = GoogleAuthProvider.getCredential(idToken, null)
                Firebase.auth.signInWithCredential(firebaseCredential)
                    .addOnSuccessListener { openHomeScreen() }
                    .addOnFailureListener { showMessage("Google sign-in failed") }
            }
        } catch (e: Exception) {
            showMessage("Sign-in cancelled")
        }
    }
}

Step 5: Phone Number (OTP) Sign-In

import com.google.firebase.FirebaseException
import com.google.firebase.auth.PhoneAuthCredential
import com.google.firebase.auth.PhoneAuthOptions
import com.google.firebase.auth.PhoneAuthProvider
import java.util.concurrent.TimeUnit

private var verificationId: String? = null

fun sendOtp(phoneNumber: String) { // format: +919876543210
    val callbacks = object : PhoneAuthProvider.OnVerificationStateChangedCallbacks() {
        override fun onVerificationCompleted(credential: PhoneAuthCredential) {
            signInWithPhone(credential) // OTP read automatically on some devices
        }
        override fun onVerificationFailed(e: FirebaseException) {
            showMessage(e.localizedMessage ?: "Could not send OTP")
        }
        override fun onCodeSent(id: String, token: PhoneAuthProvider.ForceResendingToken) {
            verificationId = id
            showMessage("OTP sent")
        }
    }

    val options = PhoneAuthOptions.newBuilder(Firebase.auth)
        .setPhoneNumber(phoneNumber)
        .setTimeout(60L, TimeUnit.SECONDS)
        .setActivity(this)
        .setCallbacks(callbacks)
        .build()
    PhoneAuthProvider.verifyPhoneNumber(options)
}

fun verifyOtp(code: String) {
    val id = verificationId ?: return
    signInWithPhone(PhoneAuthProvider.getCredential(id, code))
}

private fun signInWithPhone(credential: PhoneAuthCredential) {
    Firebase.auth.signInWithCredential(credential)
        .addOnSuccessListener { openHomeScreen() }
        .addOnFailureListener { showMessage("Wrong OTP") }
}

Tip: While testing, add test phone numbers with fixed codes under Authentication → Sign-in method → Phone, so you do not spend money on real SMS.

Step 6: Anonymous Login and Upgrading to a Real Account

import com.google.firebase.auth.AuthCredential

// Let the user explore as a guest
fun continueAsGuest() {
    Firebase.auth.signInAnonymously()
        .addOnSuccessListener { openHomeScreen() }
}

// Later, keep the same UID and data when the guest signs in with Google or phone
fun upgradeGuest(credential: AuthCredential) {
    Firebase.auth.currentUser?.linkWithCredential(credential)
        ?.addOnSuccessListener { showMessage("Account saved!") }
        ?.addOnFailureListener { showMessage("This account is already in use") }
}

Step 7: Check the Signed-In User and Sign Out

override fun onStart() {
    super.onStart()
    val user = Firebase.auth.currentUser
    if (user != null) {
        openHomeScreen() // already signed in
    }
}

fun signOut() {
    Firebase.auth.signOut()
    openLoginScreen()
}

Step 8: Protect Your Data with Security Rules

This Firestore rule lets each user read and write only their own profile document:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }
  }
}

Step 9: Verify the User on Your Own Server

If your app calls your own API, send the ID token in the Authorization header, and verify it on the server. Here is a Python Flask example that works on Cloud Run (pip install flask firebase-admin):

import os

import firebase_admin
from firebase_admin import auth
from flask import Flask, abort, g, jsonify, request

firebase_admin.initialize_app()
app = Flask(__name__)


@app.before_request
def verify_user():
    header = request.headers.get("Authorization", "")
    if not header.startswith("Bearer "):
        abort(401)
    try:
        g.user = auth.verify_id_token(header.split(" ", 1)[1])
    except Exception:
        abort(401)


@app.get("/profile")
def profile():
    return jsonify(uid=g.user["uid"], email=g.user.get("email"))


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

On Android, get the token with Firebase.auth.currentUser?.getIdToken(false) and add it as Authorization: Bearer <token>. On Cloud Run, the Admin SDK uses the attached service account automatically.

Firebase Authentication Pricing

Feature	Cost
Email, social (Google, Apple, etc.) and anonymous login	No cost in standard Firebase Authentication
Phone (SMS) login	Charged per SMS sent; price depends on the country
Identity Platform upgrade (MFA, SAML, OIDC, blocking functions)	First 50,000 monthly active users free for standard providers, then billed per user
SAML / OIDC users (with upgrade)	First 50 monthly active users free, then about $0.015 per user
Spark (free) plan with the upgrade	Limited to 3,000 daily active users

Prices change from time to time, so check the official Identity Platform pricing page before planning. Every SMS is billed even if the user never enters the OTP, so add App Check and per-region SMS limits to avoid SMS fraud.

Firebase Authentication Best Practices and Common Mistakes

• Forgetting Security Rules: Login without rules protects nothing. Always check request.auth in Firestore and Storage.
• Missing SHA fingerprints: Google and Phone sign-in fail on Play Store builds if the Play app signing SHA-1 and SHA-256 are not added.
• Trusting the app for roles: Never decide “admin” inside the app. Use custom claims set from the server.
• Skipping email verification: Check user.isEmailVerified before giving full access.
• Too many login buttons: Two or three options convert better than seven.
• Ignoring SMS costs: Use test numbers during development and set an SMS region policy in production.
• Not providing account deletion: Google Play and Apple expect apps with accounts to let users delete them. Call currentUser.delete() and remove their data too.

Conclusion

Authentication answers one question: “Who is this user?” Firebase Authentication answers it safely for you, with 9 ready-made types ranging from email and phone OTP to Google, Apple, anonymous guests and enterprise SSO.

Start simple: Google Sign-In plus phone OTP or email, protected by Security Rules and App Check. Add anonymous login for guests, and MFA or SAML when your app grows into finance or enterprise use. For the full reference, see the official Firebase Authentication documentation.

FAQs

Q1: What is Firebase Authentication in simple words?
It is Google’s ready-made login service. It lets users sign in with email, phone OTP, Google, Apple and more, and gives each user a unique ID your app can use.

Q2: Is Firebase Authentication free?
Email, social and anonymous sign-in are free in standard Firebase Authentication. Phone login is charged per SMS, and the Identity Platform upgrade is billed after its free tier.

Q3: How many types of authentication does Firebase support?
In practice, 9 types: email and password, email link, phone OTP, Google, Apple, other social providers, anonymous, custom tokens and SAML/OIDC. MFA can be added on top.

Q4: Which Firebase Authentication type is best for Indian apps?
Phone OTP plus Google Sign-In is the most common and user-friendly combination for Indian consumer apps.

Q5: What is the difference between authentication and authorization?
Authentication checks who you are. Authorization decides what you are allowed to do. In Firebase, Authentication handles the first, and Security Rules or custom claims handle the second.

Q6: Can one user log in with both Google and phone?
Yes. Use account linking, and both methods will point to the same Firebase UID and the same data.

Q7: Can I use Firebase Authentication with my own backend?
Yes. Send the user’s ID token to your server and verify it with the Firebase Admin SDK, as shown in Step 9.