Ikegbo Ogochukwu

Posted on May 11

Implementing Facebook Login in Flutter with Meta and Firebase: The Configuration Guide Most Teams Actually Need

#flutter #mobile #android #auth0challenge

Subtitle

How to set up Meta for Developers, Business ownership, Firebase Authentication, and native mobile config without mixing up App Domains, key hashes, and redirect URIs

Introduction

Facebook Login looks simple from the Flutter side. In code, it can be as small as calling FacebookAuth.instance.login(), converting the token to a Firebase credential, and signing the user in.

The real complexity is not in the Dart code. It is in the configuration spread across four systems:

Meta for Developers
Meta Business ownership and app access
Firebase Authentication
Native Android and iOS app configuration

If one of those layers is misconfigured, the failure usually shows up as a vague login cancellation, invalid OAuth redirect, key-hash error, or a token exchange failure. That is why treating Facebook Login as a console-configuration workflow, not only a code task, saves time.

This guide explains the full setup path using abstract examples instead of production identifiers.

1. Understand the flow before configuring anything

In a Firebase-backed Flutter app, the Facebook login flow usually works like this:

The app launches the Facebook login flow using the native Facebook SDK through a Flutter plugin.
Facebook returns an access token to the app.
The app converts that Facebook token into a Firebase credential.
Firebase signs the user in and issues a Firebase ID token.
Your backend can then verify the Firebase token and create or update the app-specific user session.

That means Meta is not replacing Firebase. Meta is the identity provider, Firebase is the authentication broker, and your backend remains the application session authority if your product uses its own access and refresh tokens.

2. Start with a real Meta developer account

Before you can create a Facebook app, you need to register as a Meta developer.

Meta's developer registration flow requires:

a Facebook account
agreement to Meta's platform terms and policies
verification of your account contact details

Meta's documentation states that developer verification is based on confirming the phone number and email address you provide for developer notifications. In practice, the exact verification flow can vary depending on the account and region.

The practical takeaway is simple:

do not build the app under a throwaway personal Facebook account
use an account your organization can retain access to
enable two-factor authentication

Useful references:

3. Use a Business-owned app, not a personal orphan app

This is the part many teams skip until they run into access problems.

Even if a single developer creates the app initially, the long-term owner should be the business, not one person's personal account. A proper Meta Business portfolio helps with:

shared ownership
teammate access
future app review or verification requests
preserving control if a developer leaves

For a simple Facebook Login integration that only requests minimal data, business verification may not be the first blocker. But for production ownership, review, and future scaling, organizing the app under the correct business from the beginning is still the better decision.

Keep this distinction clear:

developer account: the person who can access Meta for Developers
business portfolio: the organization that should own the app and related assets

4. Meta app setup has three different configuration buckets

This is where the confusion usually starts. Developers often mix up values that belong in completely different places.

Basic Settings

This area is about the identity of your Meta app.

Typical values here include:

app name
app contact email
privacy policy URL
app domains

The important trap: App Domains is not the same thing as Firebase's OAuth redirect URI.

App Domains should represent the real public domain associated with your app or website. In practice, this is the host that serves your public web presence or policy pages.

Example:

exampleapp.com
auth.exampleapp.com

Do not put these in App Domains:

https://sample-project.firebaseapp.com/__/auth/handler
any URL with https://
callback paths
localhost
Android package names

That guidance aligns with how Meta uses the field. OAuth redirect URIs belong elsewhere.

Facebook Login product settings

This is where you configure login-specific callback handling.

If you use Firebase Authentication with Facebook as a provider, Firebase requires the OAuth redirect URI from Firebase Console to be added to your Facebook app.

Example redirect URI:

https://sample-project.firebaseapp.com/__/auth/handler

This belongs in:

Facebook Login
Settings
Valid OAuth Redirect URIs

Reference:

Firebase Federated Authentication Docs

Platform settings

Meta also needs to know which native apps are allowed to use the Meta app.

For Android, Meta requires:

package name
default activity class
development and release key hashes

For iOS, Meta requires:

bundle identifier registration

These are platform identity values, not OAuth redirect values.

References:

5. Firebase sits in the middle of the sign-in flow

Firebase's Flutter authentication documentation describes the Facebook setup in a very direct way:

create a Facebook Developer App
enable Facebook provider in Firebase Console
add the Facebook App ID and App Secret
use a native Facebook SDK path on Android and iOS
authenticate using FacebookAuthProvider.credential(...)

Firebase also highlights two important details:

the Facebook provider must be enabled in Firebase Console
the Firebase OAuth redirect URI must be added to the Facebook app

That is why setup order matters. If Meta is configured but Firebase is not, the native token may be returned while Firebase authentication still fails.

Reference:

Firebase Auth for Flutter

6. Native mobile config still matters in a Flutter project

Flutter does not remove the need for native Facebook settings.

Meta's Android setup requires:

facebook_app_id
facebook_client_token
fb_login_protocol_scheme
manifest metadata
Facebook activities
Custom Tab configuration
INTERNET permission
package/class association
key hashes

Meta's iOS setup requires:

CFBundleURLSchemes
FacebookAppID
FacebookClientToken
FacebookDisplayName
LSApplicationQueriesSchemes
bundle ID registration

Even in Flutter, Facebook Login still relies on native Android and iOS configuration under the hood.

7. What a properly configured project usually contains

In a typical Flutter + Firebase + Facebook Login project, you will usually have:

flutter_facebook_auth
a login flow calling FacebookAuth.instance.login()
Firebase credential conversion
Android package identifiers
iOS bundle identifiers
native Android metadata
iOS Info.plist Facebook entries
Firebase Authentication enabled
a configured Firebase auth domain

At that stage, the remaining work is often:

aligning Meta console settings with native identifiers
adding Android debug and release key hashes
enabling Facebook provider in Firebase
confirming the correct ownership and admin structure

8. Business portfolio is operational hygiene, not bureaucracy

If you are building a real product, business ownership matters for reasons beyond compliance.

Without proper business ownership, you can run into:

one developer privately owning the Meta app
broken access when people leave the team
confusion over who can submit apps for review
delays when Meta later requests verification

For a small team, the disciplined approach is:

create or select the correct business portfolio
make the business the long-term owner
assign appropriate admin and developer roles
keep business documentation ready if verification is requested

9. Testing should happen in stages

A reliable testing sequence looks like this:

Confirm Facebook provider is enabled in Firebase.
Confirm Android and iOS platform values are correct in Meta.
Add Android debug key hash and test debug builds.
Add Android release key hash and test release builds.
Test iOS on a real device if shipping on iOS.
Confirm Firebase user creation succeeds.
Confirm backend session creation succeeds.
Test logout and account deletion flows.

If you only test debug Android builds, you can still ship a broken production login flow.

10. Common mistakes to avoid

putting the Firebase redirect URI into App Domains
forgetting Android release key hashes
enabling Facebook Login in Meta but not in Firebase
exposing the Facebook App Secret in Flutter code
registering the app under the wrong personal account
assuming Flutter removes native setup requirements
testing only in development mode

Final takeaway

Facebook Login in Flutter is not mainly a Dart problem. It is a configuration and ownership problem.

The teams that get it right usually do four things well:

they create the Meta app under a durable owner
they align Meta settings, Firebase settings, and native mobile settings
they understand the difference between App Domains and OAuth redirect URIs
they test both debug and release login paths

Once those pieces are aligned, the Flutter implementation becomes the easy part.

DEV Community