Back to Insights

React Native · Published 2026-08-15 · 6 min read · Waris Labs

React Native Firebase Authentication: Practical Production Setup

Set up Firebase Authentication in a React Native app with auth state handling, profile separation, password reset, error handling, and production security checks.

Published by Waris Labs, a software engineering studio publishing practical guides on React Native, Firebase, cloud systems, app publishing, and AI automation.

Waris Labs Insights are educational technical notes. Verify platform requirements, security impact, and production behavior before applying code or configuration changes.

Authentication is one of the first systems users touch and one of the easiest systems to make messy. In a React Native app, Firebase Authentication can handle account identity, sign-in methods, password reset, and auth state. The product still needs a clean app architecture around it.

The goal is not just to let a user sign in. The goal is to keep session state reliable, separate identity from profile data, handle errors without leaking information, and make production review easier.

Key Takeaways

  • Firebase Auth should be the source of truth for identity and session state, not a cached isLoggedIn flag.
  • Product profile data belongs in Firestore or another app database, usually keyed by the authenticated uid.
  • Error messages should help real users without confirming whether an account exists.
  • Firestore security rules and emulator tests are part of the auth implementation, not a separate cleanup step.

Auth Is Identity, Not the Whole User Profile

Firebase Auth stores the core identity record: user ID, email, provider, email verification state, and related auth metadata. Your app-specific profile belongs in Firestore or another database:

Firebase Auth
  uid
  email
  provider

Firestore
  users/{uid}
    displayName
    unitSystem
    timezone
    onboardingComplete

This separation matters because security rules and product data evolve differently from sign-in identity. For example, a fitness app may need goals, body metrics, and notification preferences. Those should not be squeezed into an auth profile object.

For a Firestore structure built around user-owned fitness data, see Firebase Firestore Architecture for a React Native Fitness App.

Enable the Sign-In Provider

For email and password authentication, enable the provider in Firebase Console before shipping. Firebase's official password authentication guide describes the basic web SDK methods and provider setup: Authenticate with Firebase using Password-Based Accounts.

React Native projects commonly use either the Firebase JavaScript SDK or React Native Firebase. Follow the package that matches your app architecture. React Native Firebase's auth usage guide is here: React Native Firebase Authentication.

Auth State Should Drive App State

Do not decide whether a user is logged in from a cached boolean such as isLoggedIn. The source of truth should be the Firebase auth state observer.

import auth from '@react-native-firebase/auth';

export function subscribeToAuthState(onUserChanged: (uid: string | null) => void) {
  return auth().onAuthStateChanged((user) => {
    onUserChanged(user ? user.uid : null);
  });
}

The app can then load the user's profile document after the auth state is known. Keep the loading state explicit:

  • checkingAuth
  • signedOut
  • signedInMissingProfile
  • signedInReady

That prevents flickers where the app briefly shows the wrong screen.

Session Persistence

On mobile, Firebase auth sessions normally persist across app restarts through native or local persistence. Still, the UI should assume that auth restoration is asynchronous. Show a splash/loading state while Firebase restores the user.

Avoid storing passwords, refresh tokens, or custom session secrets in AsyncStorage. Let Firebase manage auth credentials. If the app needs additional sensitive tokens from your own backend, store them with a secure storage mechanism and design a revocation path.

Create the Profile Document Safely

After sign-up, create the Firestore user document using the authenticated UID:

async function createUserProfile(uid: string, email: string) {
  await setDoc(doc(db, 'users', uid), {
    email,
    onboardingComplete: false,
    unitSystem: 'metric',
    createdAt: serverTimestamp(),
    updatedAt: serverTimestamp(),
  });
}

The client can create this document if security rules allow only request.auth.uid == uid. For higher control, a backend trigger can create it after sign-up, but that adds operational complexity. Choose based on the product's security needs.

Error Handling Without Leaking Too Much

Auth errors should be useful without helping attackers enumerate accounts. For example, "Email or password is incorrect" is often safer than telling the user exactly whether the email exists.

Handle common states:

  • Invalid email format
  • Weak password
  • Wrong credentials
  • Network failure
  • Too many attempts
  • Disabled account
  • Provider not enabled

Firebase also supports password policies and email enumeration protection. If you enable stricter protection, test your UI because error codes may become less specific.

Password Reset Flow

A production password reset flow should be boring and reliable:

  1. User enters email.
  2. App calls Firebase password reset.
  3. UI shows a neutral success message.
  4. Email deep link or web flow lets the user reset.
  5. User returns to sign in.

The success message should not confirm that an email exists. A safer message is:

If an account exists for that email, a reset link has been sent.

Email Verification

Email verification is product-dependent. For some apps, users can browse before verifying but cannot sync, share, or export data. For other apps, verification is required before any authenticated use.

Whatever rule you choose, make it consistent. Do not let unverified users create sensitive data in one screen and block them in another.

Security Rules Are Part of Auth

Authentication proves who the user is. Security rules decide what the user can access.

A simplified Firestore rule shape:

match /users/{uid} {
  allow read, write: if request.auth != null && request.auth.uid == uid;
}

Real rules often need validation, immutable fields, subcollections, and admin-only paths. Test rules with the Firebase Emulator Suite before trusting them in production.

Production Checklist

Before release, verify:

  • Email/password provider is enabled.
  • Auth state observer drives navigation.
  • Sign-up creates a profile exactly once.
  • Sign-out clears local user state.
  • Password reset works from a real email.
  • Error messages are understandable.
  • Security rules prevent cross-user reads.
  • Account deletion path is documented and tested.
  • Crash reporting does not log passwords or tokens.
  • Store privacy and data safety answers mention account data accurately.

If you are preparing for Google Play, include auth flows in the release test plan from How to Prepare a React Native App for Google Play Production.

Common Mistakes

One common mistake is storing the auth user's email as the document ID. Use the UID. Emails can change and may contain characters that make paths awkward.

Another mistake is assuming profile data exists immediately after sign-in. Network failures, interrupted sign-up, or old accounts can create missing-profile states. Handle them intentionally.

A third mistake is leaving admin behavior in the client. If a field should only be changed by staff or backend logic, enforce that in rules or backend code, not by hiding a button.

Official Documentation

Firebase documents the official authentication and security rule behavior. React Native Firebase documents one common native Firebase integration path for React Native apps. The state model and release checklist in this article are Waris Labs recommendations for production app architecture.

Conclusion

Firebase Authentication can be a strong foundation for React Native apps when it is treated as identity infrastructure, not as the whole user model. Let auth state drive navigation, keep profile data in user-owned documents, handle sessions asynchronously, avoid leaking account existence, and test security rules. A clean auth setup makes every other production feature easier to reason about.

Related Articles