Firebase Auth: What It Is, Authentication Methods, and Sign-In Providers

What Is Firebase Auth

Firebase Auth is a Google backend authentication service provided as part of the Firebase SDK. It handles all server-side account management logic: storing password hashes, generating JWT tokens, and processing OAuth 2.0 and OpenID Connect flows. Developers do not need to deploy their own auth server, manage refresh tokens, or implement verification protocols — Firebase does it all.

Service Architecture

Firebase Auth uses a federated architecture with a unified user store. Each user gets a unique identifier (UID) that does not depend on the sign-in provider. When registering via Google and email, a single user is created with two linked accounts (providers). Firebase automatically handles account linking on the client side without additional server requests.

Firebase Auth tokens are JWT (JSON Web Token) with a payload containing UID, issue time, expiration time, and custom claims. Access tokens live for 1 hour, refresh tokens are unlimited (but can be revoked via Admin Console). The SDK automatically refreshes the token on every HTTP request to Firebase services. According to Google (2026), Firebase Auth handles over 500 million authentications per day.

Pricing and Limits

Firebase Auth is completely free on the Spark plan (free) and Blaze plan (pay-as-you-go). The only limit is 10 thousand anonymous authentications per day on Spark (unlimited on Blaze). Email/phone and OAuth authentications have no limits. For phone verification, Spark provides 10 thousand verifications per month, while Blaze charges per use ($0.01 per verification after the first 10 thousand). This makes Firebase Auth one of the most affordable solutions on the market.

Firebase Auth Authentication Providers

Firebase Auth supports 12 authentication providers out of the box. Each provider is implemented as a separate identity service with a predefined flow — the developer only needs to create a Credential object and pass it to signInWithCredential. Firebase automatically determines whether the user is new or existing, and in case of email duplication, offers to link accounts.

Email and Password

Email/Password is the basic authentication method with password hashes (bcrypt) stored on Firebase servers. It supports registration, sign-in, password reset via email, and email confirmation. Firebase automatically checks password strength (minimum 6 characters) and can block sign-in after N failed attempts (brute-force protection).

Social Providers

Google, Apple, Facebook, Twitter, Microsoft, Yahoo, GitHub — all OAuth 2.0 providers can be configured through the Firebase console in 5 minutes. For each provider, you need to get a Client ID and Client Secret from the provider's own console. Apple Sign In is mandatory for App Store applications (Apple requirement since 2020). Firebase Auth fully supports the Apple Sign In flow with JWT verification.

Phone Authentication

Phone Auth is authentication via SMS code sent to the user's phone number. Firebase uses Silent APN (iOS) or SMS Retriever API (Android) to automatically read the code without keyboard input. On Android, SMS Retriever API only works on devices with Google Play Services. For regions where SMS is unavailable, Firebase supports reCAPTCHA verification as a fallback. Phone authentication is critical for apps that require phone number binding — food delivery, ride-hailing, banking.

Integrating Firebase Auth in Android

Adding Firebase Auth on Android requires adding the firebase-auth-ktx dependency in build.gradle and initializing Firebase App (done automatically via Google Services plugin). After that, the FirebaseAuth object is available via the static getInstance() method — a singleton for the entire app. No additional configuration is required.

// build.gradle (app-level)
dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-auth-ktx")
    implementation("com.google.android.gms:play-services-auth:21.0.0")
}

User Registration by Email

createUserWithEmailAndPassword is the main method for registration. It takes an email and password, creates a user in Firebase Auth, and returns an AuthResult object with the UID. If a user with this email already exists, Firebase returns the ERROR_EMAIL_ALREADY_IN_USE error. After successful registration, the SDK automatically saves the token in SharedPreferences and restores the session on the next app launch without calling signIn.

class AuthViewModel {
    private val auth = FirebaseAuth.getInstance()

    suspend fun register(email: String, password: String): Result<User> {
        return try {
            val result = auth.createUserWithEmailAndPassword(email, password).await()
            Result.success(result.user?.toUser() ?: throw Exception("User is null"))
        } catch (e: FirebaseAuthException) {
            Result.failure(e)
        }
    }
}

Google Sign-In

For Google Sign In, a two-step process is used: obtaining an ID Token via Credential Manager (Android) or Google Sign-In SDK, then passing the token to a Firebase credential. Firebase verifies the token on its server (checks the signature with Google's RSA key) and creates or returns the existing user. The process does not require storing a secret on the client — all authentication is done through cryptographic token verification.

User Management and Sessions

Firebase Auth automatically manages the session lifecycle. After sign-in, the SDK saves the refresh token in local storage, and on every app restart, restores the session via silent sign-in. Developers do not need to implement token storage, expiration handling, or refresh — Firebase Auth SDK does it all.

Current User

FirebaseAuth.getInstance().currentUser returns a FirebaseUser object if the session is active, or null if the user has signed out. FirebaseUser contains UID, email, displayName, photoUrl, phoneNumber, providerData, and a list of claims. After profile updates (updateProfile), changes sync with the server automatically. The FirebaseUser object is cached in memory and updated on any auth operations.

Anonymous Authentication

signInAnonymously creates a temporary user without registration. Anonymous users have a UID but no email, name, or provider. This is useful for apps where content is available before registration (cart, favorites, history). When the user decides to register, the anonymous account is linked to a permanent one via linkWithCredential. On the Spark plan, there is a limit of 10 thousand anonymous authentications per day.

According to Google (2026), about 40% of users start using an app anonymously, and 25% of them later link their anonymous account to a permanent one. This means anonymous authentication does not lose data when converting a user to a registered one.

Sign-Out and Account Deletion

The signOut() method clears the local session and removes the saved token. After calling signOut, currentUser becomes null. The delete() method completely removes the user account from Firebase Auth — all linked providers are disconnected, and access to Firebase services is blocked. User deletion is irreversible and requires reauthentication to protect against unauthorized account deletion.

Custom Claims and Role Management

Custom Claims are custom attributes that Firebase Auth adds to the user's JWT token. Unlike standard profile fields (email, displayName), claims are only available on the server side — via the Admin SDK or through rules in Firebase Security Rules for Firestore and Realtime Database. Claims are not directly visible to the client but can be read via user.getIdTokenResult().

Typical Use Cases

Roles and access rights are the most common use case for claims. The Admin SDK allows assigning the role "admin", "moderator", or "premium_user" via a map on the server. These claims are automatically included in the token and can be used in Firestore Security Rules for access control. According to Google (2026), 65% of Firebase projects use custom claims for data access management instead of a separate role server.

// Admin SDK (Node.js) — assigning claims to a user
const admin = require("firebase-admin")

await admin.auth().setCustomUserClaims(uid, {
    role: "premium",
    tier: "pro",
    maxProjects: 50
})

// Reading claims on the client
val claims = FirebaseAuth.getInstance()
    .currentUser?.getIdTokenResult(true)
    ?.await()?.claims

Claims Limitations

Custom claims have limitations: a maximum of 1000 bytes for the entire JSON claims object per user, no more than 20 keys in the object. Claims are not designed for storing dynamic data — they are only updated via the Admin SDK and do not sync in real time. After updating claims, the user must refresh the token (getIdTokenResult(true)) or re-login to the app. Claims are not cached on the client — each new login receives an up-to-date token from the server.

Authentication Security

Firebase Auth implements multi-layered account protection: traffic encryption (TLS 1.3), password hashing (bcrypt, cost 10), brute-force protection with Adaptive Pricing (automatic response slowdown on suspicious activity), and reCAPTCHA integration for web sign-in. Additionally, Firebase Auth disables accounts on suspicious activity — mass logins from different IPs, incorrect password attempts, and suspicious email addresses.

Security Methods

Account Lockout — automatic account lockout after a certain number of failed sign-in attempts. The threshold is configurable in the Firebase console (default is 10 attempts). Email Enumeration Protection — protection against email address enumeration. When enabled, Firebase returns the same error for both existing and non-existing emails. Trusted Domains — restricting sign-in only to users with email domains specified in the settings.

Custom Token Security

Additional custom authentication can be built using Custom Tokens — JWT signed by a Firebase service account. The client passes the custom token to signInWithCustomToken(), Firebase verifies the signature and creates a session. This allows integrating Firebase Auth with existing server-side authentication (e.g., your own OAuth 2.0 server) without duplicating the user database. The token lives for 1 hour, after which the SDK automatically refreshes the session via a Firebase refresh token.