FlutterFlow Firebase Auth Errors: The Real Fixes (2026)

If your FlutterFlow app builds fine but login silently fails, throws "configuration not found," or returns PERMISSION_DENIED, you are not missing anything exotic. FlutterFlow generates clean Firebase Auth code. The errors almost always come from the wiring between three systems that have to agree with each other: your Firebase project, your Apple Developer and Google Cloud accounts, and the config files baked into the build. When one of them drifts out of sync, auth breaks.

This guide walks the real fixes in the order we actually check them, with accurate steps. It is written for people whose FlutterFlow Firebase authentication is not working and who want to stop guessing.

Start here: a 60-second triage

Before changing anything, figure out which layer is failing. The error message is the first clue.

Fix 1: SHA-1 and SHA-256 fingerprints for Google sign-in

This is the single most common reason Google sign-in fails on Android in FlutterFlow. Google sign-in needs to know which app signing keys are allowed to request a login. If the fingerprint for the key that signed your build is not registered in Firebase, the sign-in flow opens and then quietly cancels.

You usually have two or three keys, and all of them need fingerprints registered:

• Debug key for builds you test from FlutterFlow or locally.
• Upload key if you sign your own release builds.
• Google Play app signing key if you publish through the Play Store, which re-signs your app with its own key.

Steps that actually work:

• Get the SHA-1 and SHA-256 for your debug key. On your machine, run the keytool command against the debug keystore (typically keytool -list -v -keystore ~/.android/debug.keystore with the standard android password). Copy both the SHA-1 and SHA-256 values.
• If you have published to Google Play, open Play Console > your app > Setup > App integrity > App signing. Copy the SHA-1 and SHA-256 for both the app signing key and the upload key.
• In the Firebase console, go to Project settings > General > Your apps > the Android app, and add every fingerprint under "SHA certificate fingerprints." Add SHA-256 as well as SHA-1. Google sign-in and newer Google APIs increasingly require SHA-256.
• Download the refreshed google-services.json after adding fingerprints, because the file changes when keys are added.

After adding fingerprints, fingerprint propagation is not always instant. Give it a few minutes, then rebuild. If you tested a Play Store build, remember it is signed by Google's key, so the Play app signing SHA must be present or store builds will fail even when your debug build works.

Fix 2: google-services.json and GoogleService-Info.plist mismatches

These two files tell your app which Firebase project to talk to. FlutterFlow injects them during the build. If they belong to a different Firebase project, an old project, or the wrong bundle identifier, auth and Firestore calls fail in confusing ways, including "configuration not found."

Check the following:

• Project match. The project_id in google-services.json and the PROJECT_ID in GoogleService-Info.plist must both match the Firebase project you are actually editing in the console. It is easy to wire FlutterFlow to one Firebase project and edit settings in another.
• Bundle identifier match. The iOS bundle ID in your plist and the Android package name in your JSON must match the app records in Firebase exactly, and match what FlutterFlow ships. A trailing typo or a dev-vs-prod suffix mismatch breaks auth.
• Single source of truth. In FlutterFlow, set up Firebase through the built-in Firebase setup flow rather than pasting files by hand, then let it regenerate the config. Manual files and the auto-generated ones can conflict.
• Re-download after every change. Any time you add an app, change a bundle ID, add a fingerprint, or enable a provider, the config files can change. Re-run the Firebase setup in FlutterFlow so the new files are baked into the next build.

A quick honest tally of where the two files differ:

Fix 3: enable the provider you are actually using

FlutterFlow can drop a Google or Apple or email button into your UI before the matching provider is turned on in Firebase. When the provider is off, you get auth/operation-not-allowed or "this operation is not allowed."

In the Firebase console, open Authentication > Sign-in method, and enable each provider you call from the app: Email/Password, Google, Apple, Phone, or whatever else. For Google, confirm a support email is set. For Apple, the provider has its own fields you must complete (covered below). Enabling the provider here is separate from adding the button in FlutterFlow. Both have to be done.

Fix 4: authorized domains for web and previews

If you test in FlutterFlow's web preview, run a web build, or deploy to a custom domain, Firebase blocks auth from domains it does not recognize. The error is auth/unauthorized-domain.

Go to Authentication > Settings > Authorized domains and add every domain auth runs on:

• localhost for local testing.
• Your Firebase Hosting domains (the .web.app and .firebaseapp.com ones are there by default).
• Any custom domain you deploy to.
• The FlutterFlow preview domain if you authenticate inside the in-app web preview.

This only affects web-based auth flows. Native iOS and Android sign-in does not use the authorized-domain list, so if mobile works and web does not, this is your fix.

Fix 5: "configuration not found" (CONFIGURATION_NOT_FOUND)

This error usually means one of two things, and it is worth checking both:

• The provider or Identity Platform configuration does not exist. The provider was never enabled, or the project the app is pointing at is not the one where you enabled it. Re-check Fix 2 (project match) and Fix 3 (provider enabled). Nine times out of ten the app is talking to a different Firebase project than the one you have been configuring.
• The app config is stale. You enabled the provider after the last build, so the baked-in config predates the change. Re-run Firebase setup in FlutterFlow and rebuild.

If you recently migrated the project to Google Cloud Identity Platform, confirm the auth configuration was carried over. A half-migrated project can throw this error even when everything looks enabled in the console.

Fix 6: PERMISSION_DENIED is usually not an auth bug

This one trips people up. If a user can log in but then cannot read or write data, the login worked. PERMISSION_DENIED comes from your Firestore or Realtime Database security rules, not from Firebase Auth.

What to check:

• Rules require an authenticated user, but the request is unauthenticated. Common when a screen loads and queries Firestore before sign-in completes. Gate the query so it only runs after the auth state is ready.
• Rules check a field that does not match. For example, a rule requiring request.auth.uid == resource.data.ownerId fails if your documents store the owner under a different field name.
• You are still on locked test rules. Default test-mode rules expire and then deny everything. Replace them with real rules that allow your authenticated reads and writes.
• Wrong project again. If the app reads from a different project than the one whose rules you edited, you will see denials no matter what the rules say.

The fix is almost always in the Firestore/Database Rules tab, written to match how your data and your request.auth claims are actually shaped.

Fix 7: Apple sign-in setup, end to end

Apple sign-in is the most setup-heavy provider because it spans Apple Developer, Firebase, and (for web or Android) a Service ID. Miss one step and the button does nothing. Apple also requires that if you offer any third-party sign-in (like Google), you offer Sign in with Apple too, so most teams need this working before App Store review.

The accurate sequence:

• Enable the capability. In your Apple Developer account, on the App ID for your bundle identifier, enable the "Sign In with Apple" capability.
• Enable the provider in Firebase. Authentication > Sign-in method > Apple, and turn it on. For native iOS-only sign-in, that is often all Firebase needs.
• For web or Android, create a Service ID. In Apple Developer, create a Services ID, enable Sign In with Apple on it, and configure the return URL to the Firebase auth handler (your project's firebaseapp.com callback). Then create a private key for Sign In with Apple, and enter the Service ID, Apple Team ID, Key ID, and the private key into the Firebase Apple provider settings.
• Match the bundle ID. The bundle identifier in FlutterFlow, in the App ID, and in GoogleService-Info.plist all have to agree.
• Rebuild and test on a real device. Apple sign-in behaves differently in simulators, so verify on hardware before concluding it is broken.

FAQ

Why is my FlutterFlow Google sign-in not working on Android but fine on iOS?

Almost always a SHA fingerprint problem. Android Google sign-in validates the signing key against the SHA-1 and SHA-256 fingerprints registered in Firebase, while iOS uses a URL scheme instead. Add the debug, upload, and Google Play app-signing fingerprints in Firebase Project settings, re-download google-services.json, and rebuild.

What does CONFIGURATION_NOT_FOUND mean in FlutterFlow Firebase auth?

It means the auth configuration the app is asking for does not exist in the project it is pointing at. Either the sign-in provider was never enabled, or the app's config file references a different or stale Firebase project. Confirm the project IDs match, enable the provider, re-run Firebase setup in FlutterFlow, and rebuild.

Why do I get PERMISSION_DENIED after a user logs in successfully?

Because PERMISSION_DENIED comes from Firestore or Realtime Database security rules, not from authentication. The login worked; the data request was blocked. Check that your rules allow the authenticated user to read or write the specific documents, that queries do not fire before auth state is ready, and that you are not still on expired test-mode rules.

Do I need both SHA-1 and SHA-256 fingerprints?

Add both. SHA-1 has long been required for Google sign-in, and SHA-256 is increasingly required by newer Google APIs and by Play app signing. Registering both for every key (debug, upload, and Play app signing) is the safest path and avoids hard-to-diagnose failures on store builds.

Why does Sign in with Apple work in TestFlight but fail elsewhere, or vice versa?

Apple sign-in commonly fails when a step in the chain is missing. For native iOS it needs the capability on the App ID plus the provider enabled in Firebase. For web or Android it additionally needs a Service ID, return URL, and a private key entered in Firebase. Simulators also behave differently from real devices, so always test on hardware, and make sure the bundle ID matches everywhere.

The bottom line

FlutterFlow plus Firebase auth is fixable, and the failures are predictable: fingerprints, config-file mismatches, an unenabled provider, authorized domains, and rules masquerading as auth errors. Work the list in order and most apps come back to life within an hour. The harder truth is that this list never really ends. Every time iOS or Android ships an update, a certificate expires, or a provider changes its requirements, something in this chain can drift, and you are back in the console.

That ongoing maintenance is exactly what we take off your plate. Rehost is a done-for-you operator based in Los Angeles. We design, build, host, monitor, and operate custom apps and websites, including the auth setup, the fingerprints, the provider configuration, and the App Store and Play submissions. Your team never logs into a dashboard or debugs a config file. You send a plain message and we ship the change. You still own the app, both developer accounts, the domain, the code, and your customer data, all portable if you ever leave. Business pricing starts at $950/mo (billed by monthly active users, as of 2026), month to month, with no setup fee, and a full app build typically takes about two weeks. You can read how the model works, see the tiers on the pricing page, estimate yours with the app calculator, or just tell us what you are building and we will tell you honestly whether done-for-you is the right fit.