Skip to content

Authentication #368

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
3 changes: 3 additions & 0 deletions docs/troubleshooting/authentication/_category_.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"label": "Authentication"
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
---
keywords: ['homepage', 'run mode', 'authentication state', 'session data']
slug: /app-starts-from-homepage-in-run-mode
title: App Starts from HomePage in Run Mode
---
# App Starts from HomePage in Run Mode

If your app always redirects to the **HomePage** in **Run Mode**, even after a previous login, it's likely caused by **retained authentication state** or **cached session data** in your browser.

## Troubleshooting Steps

- Clear your browser cache and history.

![How to clear browser cache](../assets/20250430121300291232.png)

- Try a different browser or use incognito/private browsing mode to see if the issue persists.

If the problem continues, consider checking your authentication flow and session management in your app settings.

:::tip[Reset Authentication State in Run Mode]
When using **Run Mode**, FlutterFlow preserves your **authentication state** across sessions. To test your app from a clean state, add a **"Log Out"** button on your HomePage that triggers the `Sign Out` action. This ensures the app starts from the login screen during your next test.
:::




63 changes: 63 additions & 0 deletions docs/troubleshooting/authentication/check_firebase_login_method.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
---
keywords: ['firebase', 'auth', 'authenticated']
slug: /check-firebase-login-method
title: Check Firebase Login Method
---
# Check Firebase Login Method

Understanding which authentication method a user has used can be useful for several reasons. For example, it can be leveraged for analytics, user support, and to customize the user's experience based on their login method. This method, however, is specific to Firebase Authentication.​

In our Flutter app, we can find out which method a user used to authenticate by leveraging Firebase's `User.providerData` property. Let's take a closer look at how this works in the code:


```
import 'package:firebase_auth/firebase_auth.dart';

String getUserSignInMethod() {
final user = FirebaseAuth.instance.currentUser;
String signInMethod;

for (var info in user!.providerData) {
signInMethod = info.providerId;
}

return signInMethod;
}

```

Here's a breakdown of the code:

- We first import the [Firebase Auth](https://pub.dev/packages/firebase_auth) package which gives us access to Firebase's authentication methods.

- Next, we define a function `getUserSignInMethod`. This function will return a string indicating the sign-in method the user used.

- Inside the function, we obtain the current user from FirebaseAuth using `FirebaseAuth.instance.currentUser`.

- We then declare a string `signInMethod` that will store the name of the provider used for sign-in.

`user.providerData` is an iterable that provides UserInfo for each sign-in method used by the user. We loop over this iterable using a `for` loop.

In each iteration, we assign the `providerId` to our `signInMethod` string. The `providerId` can be 'google.com' for Google, 'facebook.com' for Facebook, and 'password' for email and password.

After the loop is done, the function returns `signInMethod` string which indicates the sign-in method the user used.

The function `getUserSignInMethod()` returns a String value which corresponds to the providerId of the user's sign-in method.

Here are examples of how the return value might look:

- If the user has signed in using Google, the function will return: **`'google.com'`**

- If the user has signed in using Facebook, the function will return: **`'facebook.com'`**

- If the user has signed in using Email and Password, the function will return: **`'password'`**

These are the identifiers used by Firebase to represent different sign-in methods.
Please thoroughly test this function to ensure it fits your specific requirements

:::tip[Use Sign-In Method to Drive Dynamic UI in FlutterFlow]
In FlutterFlow, if you want to display or use the user's sign-in method in your UI logic (example, showing different UIs for Google vs. email login), you can create a custom function using the `providerId` approach shown in the article and **connect it to a custom action**. This allows you to make dynamic decisions inside your app based on how the user authenticated.

Remember to return the result from the custom function and store it in an App State variable for easy access throughout your app.
:::

Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
---
keywords: ['authentication', 'api', 'configuration']
slug: /custom-authentication-in-flutterflow
title: Custom Authentication in FlutterFlow
---
# Custom Authentication in FlutterFlow

:::info[Prerequisites]
Ensure you have a **custom server** with login and sign-up endpoints that return a JWT token upon success.

**Custom authentication** must be enabled in FlutterFlow, with entry and logged-in pages correctly set.
:::

Here's an example:

![](../assets/20250430121149388590.png)

## How to Fix Custom Authentication Issues in FlutterFlow

### 1. Verify Server and API Endpoints
- Confirm that your server correctly returns JWT tokens for login and sign-up requests. The server's response should include the **authentication token**, **refresh token**, **expiration time**, and **user ID (UID)**.
- Double-check the API endpoint configurations in FlutterFlow to ensure they match your server’s requirements.

### 2. FlutterFlow Configuration
- Make sure **Custom Authentication** is enabled in your project settings.
- Verify that the **Entry Page** and **Logged In Page** are correctly set.

### 3. UI Configuration
- Ensure your app includes the essential pages for the authentication flow: **Login**, **Sign Up**, and **Home Page** (the page shown when a user is authenticated).

### 4. API Integration and Authentication Flow
- Test API calls from FlutterFlow to your custom server to confirm responses are working as expected.
- Use the **Backend Call** action to trigger login/signup, then handle the **Custom Login** action using the response data.

### 5. Handling Tokens and User Data
- Parse the API response properly to extract and store:
- `auth token`
- `refresh token`
- `expiration time`
- `user ID (UID)`
- Store these values in local state or secure app storage.

![](../assets/20250430121149749937.png)

### 6. Navigation
- If navigation does not occur automatically after login/signup:
- Disable automatic navigation.
- Use a **manual navigation** action to route users to the appropriate page.

:::tip[General Tips]
- Test your flow with **dummy credentials** before using real user data. This helps debug token handling, API responses, and navigation.
- Add **logging** on both the server and in FlutterFlow (e.g., using snack bars or alerts) to monitor each step of the flow.
- Verify the full flow—from login to protected pages—to ensure everything works as expected.
:::

:::info[More Resources]
- [FlutterFlow Custom Authentication Video](https://www.youtube.com/watch?v=hnX3CvBtGvI)
- **Sample project:** [Custom Auth Checklist](https://app.flutterflow.io/project/custom-auth-checklist-fdjkno)
- [FlutterFlow Custom Authentication Documentation](https://docs.flutterflow.io/data-and-backend/custom-authentication)
:::
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
keywords: ['firebase-auth', 'delete-user', 'firestore-cleanup']
slug: /deleting-firebase-users-and-related-data-in-flutterflow
title: Deleting Firebase Users and Related Data in FlutterFlow
---
# Deleting Firebase Users and Related Data in FlutterFlow

![](../assets/20250430121300815719.png "Screenshot showing the delete user action")

## Understanding the Delete Action

The delete action in Firebase is designed to remove the user from the authentication table only. This means the user's document in the database will not be affected. If you want to delete the user's document from the database as well, you'll need to create a custom action with some custom code.

## Logging Out After Deletion

After completing the delete action, it is important to log out the user. Since the user no longer exists in the authentication system, logging out ensures the app routes the user back to the login page, which is typically the initial page of your project.

## Steps for Proper User Deletion

1. **Delete related data first:**
Before calling the delete user action, delete any related data such as Firestore documents or Storage files associated with the user. Once the user is deleted from Firebase Auth, their UID will no longer be accessible in the app session, making it difficult to reference their data afterward.

2. **Handle re-login behavior:**
Keep in mind that if the same user signs in again using the same signup method, Firebase will create a new document in the database for them. This happens because Firebase links the new login information to the old user document.

:::tip[Important Tips for Deleting Users]
- Always delete associated user data from Firestore or Storage **before** deleting the user from Firebase Auth. This prevents orphaned data and issues with data referencing.
- Remember that after deletion, the user will need to be logged out to avoid session errors.
- If the user signs in again with the same signup method, Firebase creates a new document for them, reconnecting the new login to the old user document.
:::

![](../assets/20250430121301101693.png "Screenshot illustrating user deletion flow")

:::note
The delete user action in FlutterFlow performs the same operation as manually deleting a user from the Firebase Authentication table.
:::
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
---
keywords: ['firebase', 'deployment', 'android', 'google-sign-in']
slug: /google-sign-in-troubleshooting
title: Fix Google Sign-In Issues in FlutterFlow
---
# Fix Google Sign-In Issues in FlutterFlow

If Google Sign-In isn’t working after exporting your FlutterFlow app, follow these steps based on how you’re deploying your app.


## 1. If Deployed to the Play Store via CodeMagic

If you published your app to the Play Store using FlutterFlow's CodeMagic integration:

- In the **Google Play Console**, open your app from the **All apps** list.
- Go to **Setup → App Integrity**.
- Under the **App Signing** tab, copy the **SHA-1 certificate fingerprint**.

![](../assets/20250430121440426479.png)

- In the **Firebase console**, open the same project, scroll to **Your Apps**, and select your Android app.
- Click **Add fingerprint**, paste the SHA-1, then click **Save**.

![](../assets/20250430121441325585.png)

- In FlutterFlow, go to **Settings → Firebase** and click:
- **Regenerate Config Files**
- **Generate Files**

![](../assets/20250430121442125737.png)

Re-test your app. Google Sign-In should now work correctly.


## 2. If Not Yet Published or Using Manual Signing

If you’re not using Play Store App Signing:

- Use **Keytool** or **Gradle's Signing Report** to generate your SHA-1.
- In **Firebase**, open your project settings.
- Under **Your Apps**, select the Android app and add the SHA-1 fingerprint.

![](../assets/20250430121442863891.png)

- In FlutterFlow, go to **Settings → Firebase**, then:
- **Regenerate Config Files**
- **Generate Files**

![](../assets/20250430121443525154.png)

Test the app again to confirm Google Sign-In works.


*Refer to the [Google Play Services documentation](https://developers.google.com/android/guides/overview) for more information.*


:::tip[Add Debug SHA-1 for Local Testing]
When testing Google Sign-In in FlutterFlow before publishing, add your **debug SHA-1** in Firebase.

Then go to `Settings → Firebase` in FlutterFlow and regenerate your config files.
:::
41 changes: 41 additions & 0 deletions docs/troubleshooting/authentication/permission_denied_code_403.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
---
keywords: ['permission', 'permission_denied', 'code']
slug: /permission-denied-code-403
title: 'Permission Denied: Code 403'
---

# Permission Denied: Code 403

This error typically occurs when your application or service account does not have the required permissions to access a resource in Google Cloud or Firebase.

## Code 403 Error Message

You may encounter this error due to one or more of the following reasons:

- **Invalid or misconfigured service account JSON file**
- **Insufficient permissions** assigned to the service account
- **Missing or incorrect IAM roles** for the service account
- **API not enabled** in the Google Cloud project

Do the following to fix this error:

## Check Your Service Account JSON File

Ensure you are using the correct `service-account.json` file and that it is not corrupted or expired.

## Verify IAM Roles and Permissions

Make sure the service account has the necessary roles like `Editor`, `Owner`, or other specific roles required for your use case.

## Enable Required APIs

Go to the [Google Cloud Console](https://console.cloud.google.com/apis/library) and ensure all necessary APIs are enabled for your project.

## Regenerate the Service Account Key if Needed
If you suspect the key is invalid, generate a new one and update your application configuration accordingly.

:::tip[Always Use Least Privilege Principle]
When assigning IAM roles to your service account, follow the **principle of least privilege**—only grant the minimum permissions necessary for the task. This not only reduces the risk of misconfiguration but also enhances the overall security posture of your app.
:::

If you continue to experience issues, consult the [Google Cloud IAM documentation](https://cloud.google.com/iam/docs/troubleshooting-access) or contact support for further assistance.
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
---
keywords: ['android', 'signing', 'release']
slug: /safetynet-phone-sign-in-issue-on-android-devices
title: SafetyNet Phone Sign-In Issue on Android Devices
---

# SafetyNet Phone Sign-In Issue on Android Devices

If you're experiencing issues with Firebase Phone Authentication on Android devices, especially when using emulators or testing in release mode, this guide will help you identify and resolve common problems.

Firebase uses either **SafetyNet** or **reCAPTCHA** to verify that phone number sign-in requests originate from your app. Issues typically arise when one of these verification methods is not correctly configured.


## Troubleshooting Checklist

Ensure the following configurations are in place:

- **Firebase Setup**
- Your project is correctly set up in the [Firebase Console](https://console.firebase.google.com/).
- Firebase Authentication is enabled.
- The Phone Sign-In method is activated.

- **Phone Authentication Flow**
- Prompt the user to enter their phone number.
- Send a verification code to the user's phone.
- Accept and verify the code entered by the user.

- **SafetyNet / reCAPTCHA Configuration**
- Your app includes the required Firebase and Play Services dependencies.
- SHA-1 and SHA-256 fingerprints are added to your Firebase project settings.
- Your API key is either unrestricted or allowlisted.

- **Testing Environment**
- If you're using an emulator, test on a physical device instead. Emulators may bypass or fail certain integrity checks.


## Firebase Verification Methods

Firebase uses one of the following methods to confirm the authenticity of phone sign-in requests:

### 1. SafetyNet (Deprecated)

If the device supports Google Play Services, Firebase uses **SafetyNet Attestation** to confirm the device’s legitimacy.

> :::warning[Deprecated API]
> The SafetyNet Attestation API is deprecated and has been replaced by the [Play Integrity API](https://developer.android.com/google/play/integrity).
> After **January 31, 2023**, you can no longer enable the SafetyNet API for new projects in the Google Cloud Console.
> :::

#### To use SafetyNet (if still active for your project):
- Enable **Android Device Verification (Deprecated)** in the [Google Cloud Console](https://console.cloud.google.com/).
- Ensure your app's **SHA-256** is added in the Firebase Console under **Project Settings > General > Your Apps**.
- Use the default Firebase API key or request onboarding for SafetyNet if needed.
- Monitor your quota [here](https://developer.android.com/google/play/safetynet/quotas).

![](../assets/20250430121259958091.png)


### 2. reCAPTCHA Verification

If SafetyNet is unavailable (e.g. device without Google Play Services or running on an emulator), Firebase falls back to **reCAPTCHA verification**.

- The reCAPTCHA challenge usually completes without user interaction.
- This flow requires:
- A valid **SHA-1** fingerprint added to your Firebase project.
- An **unrestricted** or **domain-allowlisted** API key (e.g. `your-project-name.firebaseapp.com`).

> Ensure both SafetyNet and reCAPTCHA flows are working to support a wider range of Android devices.


## Important for Release Builds

> :::info[Release Mode Configuration]
> When releasing your app to the Google Play Store, ensure you include the **SHA-1** and **SHA-256** keys from your **Play Console**:
>
> Navigate to:
> **Play Console → Your App → Release → Setup → App Signing**
> Then copy both **SHA-1** and **SHA-256** fingerprints and add them to Firebase Console under **Project Settings > General > Your Apps**.
> :::

![](../assets/20250430121300291238.png)


## Learn More

- [Firebase Phone Authentication (FlutterFire)](https://firebase.flutter.dev/docs/auth/phone/)
- [Using Firebase Auth in FlutterFlow](https://docs.flutterflow.io/authentication)
- [Play Integrity API Migration](https://developer.android.com/google/play/integrity)


Still stuck? Check Firebase logs, test on a physical device, and ensure your API keys and fingerprints are correctly added. Proper configuration of SafetyNet or reCAPTCHA is critical to ensuring phone number sign-in works reliably across devices.
Loading