Inconsistent behavior of providers using GoogleProvider() and AppleProvider()

[anxiety24]

Is there an existing issue for this?

• I have searched the existing issues and found no duplicates.

What plugin is this bug for?

Firebase UI OAuth Google, Firebase UI OAuth Apple

What platform(s) does this bug affect?

Android, iOS

List of dependencies used.

flutter pub deps -s list

  firebase_core: ^2.10.0
  firebase_auth: 4.12.1
  firebase_ui_auth: ^1.1.8
  firebase_ui_oauth: ^1.1.8
  firebase_ui_oauth_google: ^1.0.15
  firebase_ui_oauth_apple: ^1.0.15

Steps to reproduce

Setup the standard SignInScreen of FirebaseUIAuth with successfully configured providers GoogleProvider(clientId:) and AppleProvider() and login the existing user with the signInAnonymously method beforehand.

On the SignInScreen, using the "Sign in with Apple" option, the account is permanently created in the user management and successfully upgraded / linked to the provider. Logging in on another device after that (while being again anonymously logged in before, too) the anonymous login is overwritten in favor of the recently created account, linked with the apple provider.

However, trying the same using the GoogleProvider, the behavior seems to differ and I hope someone can either explain this behavior to me or look into the issue.

Expected Behavior

It is expected that the GoogleProvider works exactly the same as the AppleProvider in case of Sign-up, linking and especially signing in again on a different device using the same credentials.

Actual Behavior

Signing in with the GoogleProvider on another device leads to an "credentials-already-in-use" error of the framework, indicating that the credentials belong to another account and therefore cannot be linked to another (anonymous) user.

In contrast to AppleProvider, the GoogleProvider doesn't seem to recognize that the user tries to sign-in with existing credentials, so it seems impossible to sign-in with GoogleProvider like it is with AppleProvider.

Same holds true if you log out of your existing account, being automatically logged in anonymously again immediately by the app, then trying to sign-in using the same credentials used some minutes ago.

Additional Information

No response

[danagbemava-nc]

Hi @anxiety24, in your sign in with apple options, do you have hide my email enabled?

[anxiety24]

Hi @danagbemava-nc, thanks for your response. Can you be more specific in what you mean by "...your Sign in with Apple options"? I didn't find this option in the AppleProvider() object, nor in the Apple Developer Portal - identifier configuration for "Sign in with Apple".

Or do you mean what was selected by the user while signing in with Apple on the respective UI? (so using the anonymize feature of Sign in with Apple?) If that's the case I can already confirm that this doesn't affect or alter the experienced behavior as I already tested both in order to resolve the issue.

[danagbemava-nc]

Or do you mean what was selected by the user while signing in with Apple on the respective UI? (so using the anonymize feature of Sign in with Apple?) If that's the case I can already confirm that this doesn't affect or alter the experienced behavior as I already tested both in order to resolve the issue.

Yes, I was referring to the anonymizing feature provided by the sign in with apple.

How are you handling the AuthStateChangeAction, can you share the code for that?

Also, do you have email-enumeration-protection enabled? https://cloud.google.com/identity-platform/docs/admin/email-enumeration-protection

[anxiety24]

email-enumeration-protection is disabled as the project was created way before its introduction.

Actually, I'm not handling the AuthStateChangeAction in particular tbh, and leave almost everything to the plugin itself. I'm basically just intersecting specific states in order to navigate the user out of the signup/signin flow. So really nothing special here and it does work perfectly for all signup/signin actions except the case with GoogleProvider as mentioned. Here's the code for my SignInScreen-Widget (auth providers are configured elsewhere fyi):

SignInScreen(
        headerBuilder: (context, constraints, _) {
          return Padding(
            padding: const EdgeInsets.all(20),
            child: AspectRatio(
              aspectRatio: 1,
              child: Image.asset('assets/images/app_logo.png'),
            ),
          );
        },
        footerBuilder: (context, action) {
          return Padding(
            padding: const EdgeInsets.only(top: 16),
            child: Text(S.current.account_signup_toc_agreement, style: const TextStyle(color: Colors.grey), textAlign: TextAlign.center),
          );
        },
        //providers: AppUser.providerConfigs,
        actions: [
          AuthStateChangeAction((context, AuthState state) {
            debugPrint("AuthStateChangeAction => $state");
          }),
          AuthStateChangeAction<SignedIn>((context, state) {
            debugPrint("SignedIn");
            Navigator.pushReplacementNamed(context, '/');
          }),
          AuthStateChangeAction<UserCreated>((context, state) {
            debugPrint('UserCreated');
            Navigator.pushReplacementNamed(context, '/');
          }),
          AuthStateChangeAction<CredentialLinked>((context, state) {
            debugPrint('CredentialLinked');
            Navigator.pushReplacementNamed(context, '/');
          }),
        ],
      )

Additionally, I have a Model listening to changes of the Firebase User object to handle a seamless experience between permanent and anonymous sign in. Don't believe this affects the issue, but maybe of help for completeness:

FirebaseAuth.instance
        .userChanges()
        .listen((User? user) {

          debugPrint("userChanged $user");

          if (user == null) {
            signInAnonymous();
          } else {
            currentUser = user;
            updatePurchases();
            updateUserSettings();
          }

          notifyListeners();
        });

Hope this helps understanding the use case and current implementation better!

[danagbemava-nc]

Hi @anxiety24, do you have One account per email address enabled in your auth settings? If so, I think you might be running into https://groups.google.com/g/firebase-talk/c/ms_NVQem_Cw/m/8g7BFk1IAAAJ

[anxiety24]

Hey @danagbemava-nc, yep that setting is enabled and I already stumbled upon the scenario you're referring to. (and it makes total sense from a security pov)

However, that doesn't quite explain the different behavior between the two providers mentioned, as it works perfectly fine using the EmailAuth- and AppleProvider, where the latter is definitely also a trusted provider.

To further narrow down the issue, I also tried subclassing the GoogleProvider class and overriding its property shouldUpgradeAnonymous manually to false. Funnily, this resolves the signin issue (signin with Google then replaces the current anonymous user successfully), but of course causes problems while signing up then (anonymous user obviously won't be upgraded as required)

Debugging the AuthStateChangeActions while trying to sign in into an existing account linked to the respective provider, the sequence of events is as follows:

AppleProvider:

<SigningIn>
<CredentialsReceived>
<SignedIn>

GoogleProvider:

<SigningIn>
<CredentialsReceived>
<AuthFailed> => error: credentials-already-in-use

Therefore, there really seem to be differences in the implementation of the providers under the hood when it comes to this scenario. I hope that helps researching this behavior in greater detail

[danagbemava-nc]

Thanks for the details.

Labeling this for further insight from the team.

cc @lesnitsky

[yoman07]

I have the same problem. It looks that merging anonymous account using AppleProvider doesn't work. It works for Google.