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

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

@anxiety24

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

@danagbemava-nc

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.

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

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!

@anxiety24

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

@danagbemava-nc

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

@lesnitsky

Thanks for the details.

Labeling this for further insight from the team.

cc @lesnitsky

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

@yoman07

I have been digging a bit into the code. I think this is not being called for Apple:
https://github.com/firebase/FirebaseUI-Flutter/blob/main/packages/firebase_ui_auth/lib/src/providers/auth_provider.dart#L183

There is also fix #288 that @yoman07 has created. Either this or when whenever we initiate it we setup action as Link if we have a logged in user with anonymous true.

Impact of not fixing this is that we have to rebuild the UI just to support the linking flow for Apple.

Here is a workaround that worked for me. More inheritance than composition but it works.

class AppleProviderLinkOnly extends AppleProvider {
  AppleProviderLinkOnly({super.scopes});

  @override
  void mobileSignIn(AuthAction action) {
    super.mobileSignIn(AuthAction.link);
  }
}

I still think this should be fixed though. It has different behavior than Google. I think all Oauth should behave the same.

@yoman07

@yoman07 has provided a fix for this bug: #288

Could you let me know if this fixes your issue? @anxiety24 @georgeselkhoury

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

fix(ui_oauth_apple): upgrade anonymous users by linking the Apple cre…

Navigation Menu

Repository navigation

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

Is there an existing issue for this?

What plugin is this bug for?

What platform(s) does this bug affect?

List of dependencies used.

Steps to reproduce

Expected Behavior

Actual Behavior

Additional Information

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Is there an existing issue for this?

What plugin is this bug for?

What platform(s) does this bug affect?

List of dependencies used.

Steps to reproduce

Expected Behavior

Actual Behavior

Additional Information

Activity

danagbemava-nc commented on Jan 10, 2024

anxiety24 commented on Jan 10, 2024

danagbemava-nc commented on Jan 17, 2024

anxiety24 commented on Jan 17, 2024

danagbemava-nc commented on Jan 18, 2024

anxiety24 commented on Jan 18, 2024

danagbemava-nc commented on Jan 19, 2024

yoman07 commented on Feb 15, 2024

9 remaining items

georgeselkhoury commented on Sep 4, 2024

georgeselkhoury commented on Sep 4, 2024

georgeselkhoury commented on Sep 5, 2024

russellwheatley commented on Oct 28, 2024

github-actions commented on Nov 26, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions