Adding Google as a Sign-in provider

Build and publish a Flutter-based app for the App Store and Google Play — updated for 2026 with the latest Firebase and Flutter tooling.

Once you have a user signed in, you can open your mobile app to personalisation based on that individual. Google Sign-in remains one of the most frictionless ways to get there, especially for Android users — but the setup steps have evolved, and the tooling has improved considerably.

TL:DR – We now have an authenticated user connected to Google Firebase and its Cloud Firestore database. This instalment extends the app to actually do something with that connection, starting with wiring up Google as a sign-in provider.

2026 update: what's changed with Firebase Authentication

Firebase Authentication has matured significantly since this series began. The most notable shift for Flutter developers is that the google_sign_in package and firebase_auth are now tightly integrated through the FlutterFire suite, which is actively maintained and receives regular updates aligned with Flutter stable releases. The older manual configuration steps — particularly around adding SHA-1 fingerprints — are now surfaced more clearly inside the Firebase console itself, with guided prompts when it detects a missing fingerprint. The Firebase console UI has also been reorganised: the old "Develop" sidebar is gone, replaced by a cleaner product-based navigation.

Additionally, Google Sign-in on Android now benefits from the Credential Manager API (introduced in Android 14 and backported), which replaces the legacy GoogleSignIn dialog with a bottom-sheet picker that feels native to modern Android. The FlutterFire team has been updating the google_sign_in plugin to support this flow, so it is worth checking the plugin changelog before starting a new project in 2026.

On iOS and macOS, Sign in with Apple remains a mandatory alternative whenever you offer any third-party sign-in — App Store policy has not changed on this point. Plan for both from the start.

Authentication sign-in providers

Authentication is essential for multiple users to retrieve their own stored data each time the app runs. Firebase supports a wide variety of authentication mechanisms, but most apps need only a handful. To find them, open the Firebase Console, select your project, then navigate to Build → Authentication → Sign-in method.

Firebase Authentication Sign-in providers

There are many providers available, but for a typical consumer app the most useful are:

  • Google
  • Apple (required on iOS if you offer any third-party sign-in)
  • Phone (SMS one-time password)
  • Email / Password
  • Anonymous (useful for onboarding before a user commits)

Google Sign-in

Android devices running Google Play Services are essentially guaranteed to support Google Sign-in, making it the lowest-friction option for the majority of Android users. iOS users frequently have a Google account too, so the provider has broad reach across both platforms. Setup is slightly more involved than anonymous auth, but the Firebase console now guides you through the most common stumbling blocks.

Add the required packages

Before touching any platform configuration, make sure your pubspec.yaml includes the current FlutterFire packages. As of 2026, the relevant entries look like this:

dependencies:
  firebase_core: ^3.x.x
  firebase_auth: ^5.x.x
  google_sign_in: ^6.x.x

Always pin to the latest stable versions listed on pub.dev rather than copying these numbers verbatim — the FlutterFire packages release frequently. Run flutter pub upgrade after editing the file.

Generate your SHA-1 fingerprint

Google Sign-in requires the SHA-1 of your signing certificate to be registered in the Firebase console. Without it, the sign-in flow will fail silently on Android. There are two straightforward ways to get this value.

Option 1: Android Studio Gradle panel

  1. Open the Android module in Android Studio by selecting Open for Editing in Android Studio from the Flutter toolbar in VS Code, or by opening the android/ folder directly.
  2. In the Gradle panel (right-hand sidebar), expand your app module and navigate to Tasks → android → signingReport. Double-click to run it.
  3. Android Studio Gradle panel
  4. The Run panel at the bottom will display your SHA-1 and SHA-256 fingerprints for both debug and release keystores. Copy the debug SHA-1 for now — you will need the release SHA-1 before you publish.
  5. Android Studio Gradle signing report output

Option 2: command line with keytool

If you prefer the terminal, keytool ships with any JDK installation. The debug keystore password is android.

$ keytool -list -v \
    -alias androiddebugkey \
    -keystore ~/.android/debug.keystore

Enter keystore password: android

Certificate fingerprints:
     SHA1: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
     SHA256: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:...

On Windows, the debug keystore lives at %USERPROFILE%\.android\debug.keystore.

Add the fingerprint to the Firebase console

  1. In the Firebase console, go to Project Settings → General → Your apps and select your Android app.
  2. Scroll to SHA certificate fingerprints and click Add fingerprint.
  3. Paste your SHA-1 value and save. Download the updated google-services.json and replace the existing file in android/app/.

This last step — re-downloading google-services.json — is easy to forget and is the most common cause of Google Sign-in mysteriously failing after the fingerprint is added.

Enable Google as a sign-in provider

  1. In the Firebase console, go to Build → Authentication → Sign-in method.
  2. Click Google and toggle it to Enabled.
  3. Set a support email address (required) and click Save.

Implement the sign-in flow in Flutter

With the packages installed and the console configured, the sign-in logic itself is straightforward. A minimal implementation looks like this:

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

Future<UserCredential> signInWithGoogle() async {
  // Trigger the Google sign-in flow
  final GoogleSignInAccount? googleUser = await GoogleSignIn().signIn();

  // Obtain auth details from the request
  final GoogleSignInAuthentication? googleAuth =
      await googleUser?.authentication;

  // Create a Firebase credential
  final credential = GoogleAuthProvider.credential(
    accessToken: googleAuth?.accessToken,
    idToken: googleAuth?.idToken,
  );

  // Sign in to Firebase with the credential
  return await FirebaseAuth.instance.signInWithCredential(credential);
}

Call signInWithGoogle() from a button tap and listen to FirebaseAuth.instance.authStateChanges() to react when the user is confirmed. Keep sign-in logic out of your widget tree — a dedicated auth service class or a state management solution such as Riverpod or Bloc keeps things testable.

Verify the sign-in worked

A successful sign-in produces log output similar to the following in your debug console:

I/FirebaseAuth( 5331): [FirebaseAuth:] Preparing to create service connection to gms implementation
D/FirebaseAuth( 5331): Notifying id token listeners about user ( xxxxxxxx ).
D/FirebaseAuth( 5331): Notifying auth state listeners about user ( xxxxxxxx ).

You can also verify directly in the Firebase console. Navigate to Authentication → Users and look for the Google icon (G) in the Providers column alongside the user's email address.

Google authenticated user in Firebase console

A note on release builds

Everything above applies to debug builds. Before you publish, you must repeat the SHA-1 (and ideally SHA-256) fingerprint process for your release keystore and add those values to the Firebase console too. If you use Google Play App Signing — which is now the default for new apps — you also need to add the SHA-1 that Google Play manages on your behalf. You can find it in the Play Console under Setup → App integrity → App signing. Skipping this step means Google Sign-in will work perfectly in testing and break the moment a user installs the production build.

What's next

The user is now authenticated, but the app doesn't yet do anything meaningful with that identity. The next instalment wires up the remaining sign-in providers — Apple, phone, and email — before we circle back to personalising the Firestore data layer based on the authenticated user's UID.