[google_sign_in] Redesign API for current identity SDKs #9267

stuartmorgan-g · 2025-05-16T17:54:14Z

This is a full overhaul of the google_sign_in API, with breaking changes for all component packages—including the platform interface. The usual model of adding the new approach while keeping the old one is not viable here, as the underlying SDKs have changed significantly since the original API was designed. Web already had some only-partially-compatible shims for this reason, and Android would have had to do something similar; see flutter/flutter#119300 and flutter/flutter#154205, and the design doc for more background.

Fixes [google_sign_in] Rework google_sign_in to reflect changes in underlying SDKs flutter#119300
Fixes [google_sign_in] Switch Android to Credential Manager flutter#154205
Fixes [google_sign_in_web] Enable incremental authorization for Code Model. flutter#139406
Fixes [google_sign_in_android] Remove deprecated API usages in most recent version of play-services-auth flutter#150365
Fixes [google_sign_in_web] Remove deprecated signIn method. flutter#137727
Fixes [google_sign_in] Implement canAccessScopes on mobile flutter#124206
Fixes google_sign_in plugin links to obsolete documentation for web flutter#117794
Fixes [google_sign_in] Android documentation is wrong flutter#107532
Fixes [google_sign_in] Support passing a nonce flutter#85439
Fixes [google_sign_in] java.lang.NullPointerException: Attempt to read from field [...] on a null object reference flutter#74308
Fixes [google_sign_in] Add future that completes when the plugin is (really) ready. flutter#71607
Fixes [google_sign_in_web] googleSignIn.signIn() hangs forever if can't connect to apis.google.com flutter#70427
Fixes [google_sign_in] better error handling flutter#32441 (there may be more to do here over time, since we may find exceptions that are not caught, but we now have a structured system to convert errors to as we find specific unhandled cases)

Pre-Review Checklist

Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

Also reworks app-facing package example app for testing.

camsim99

The Android implementation LGTM!

camsim99 · 2025-06-02T16:14:00Z

packages/google_sign_in/google_sign_in_android/lib/google_sign_in_android.dart

+  Future<PlatformGoogleIdTokenCredential?> _authenticate({
+    required bool filterToAuthorized,
+    required bool autoSelectEnabled,
+    required bool useButtonFlow,


Ok cool this is much clearer, thank you!

camsim99 · 2025-06-02T16:27:54Z

packages/google_sign_in/google_sign_in_android/README.md

@@ -13,3 +13,28 @@ should add it to your `pubspec.yaml` as usual.

 [1]: https://pub.dev/packages/google_sign_in
 [2]: https://flutter.dev/to/endorsed-federated-plugin
+
+## Integration


Hahaha totally understandable! LGTM!

stuartmorgan-g · 2025-06-03T15:00:12Z

@LongCatIsLooong / @cbracken Ping on the iOS portion of this review.

stuartmorgan-g · 2025-06-03T15:00:55Z

@bparrishMines Could you review the platform interface and app-facing package changes?

LongCatIsLooong

As someone that's new to this plugin, thanks for the design doc! I still have a few questions after reading the doc.

LongCatIsLooong · 2025-06-03T16:28:42Z

packages/google_sign_in/google_sign_in/README.md


 ### Requesting more scopes when needed

 If an app determines that the user hasn't granted the scopes it requires, it
-should initiate an Authorization request. (Remember that in the web platform,
-this request **must be initiated from an user interaction**, like a button press).
+should initiate an Authorization request. On some platforms, such as web,


nit: this sounds like there are platforms other than web where user interactions are required for Authorization request. Is that the case? How do I know which of the platforms my app targets have such restriction?

supportsAuthenticate? But that's for authentication I assume?

In practice, it's just web (and that may well be true forever). I changed this because we are generally moving toward trying to be as platform agnostic as possible in the app-facing package, because the idea of a federated plugin is that we don't know what other platforms might be supported. You make a great point though; making the README more general without providing a corresponding API just means it's vague and less actionable.

I like the idea of using support queries for this. I plumbed through an authorizationRequiresUserInteraction() for this purpose, and updated the README and API docs accordingly.

Sounds good (I don't see a new commit tho).

LongCatIsLooong · 2025-06-03T16:56:40Z

packages/google_sign_in/google_sign_in/example/lib/main.dart

-      }
-// #enddocregion CanAccessScopes
+    // #docregion Setup
+    final GoogleSignIn signIn = GoogleSignIn.instance;


Hmm this reminds me of flutter/flutter#168100, if the user connects / disconnects a mouse / keyboard on Android the activity will restart and that would result in the element tree being re-inflated anew.

I guess that does not break the new flow (from reading the docs initialize has to be called exactly once in a program) since the new activity will spin up a new dart vm? Still it would be an annoyance that every time I unplug my keyboard I have to go over the sign-in process again.

Or when the activity restarts, the lightweight authentication path will be taken and the flow will typically be invisible to user / require no additional user interactions?

EDIT: Just read the design doc and it mentioned "Fully silent sign in is no longer available"

Still it would be an annoyance that every time I unplug my keyboard I have to go over the sign-in process again.

That's up to whether the app developer chooses to include auth state in their state restoration.

Or when the activity restarts, the lightweight authentication path will be taken

That's up to the app developer too.

include auth state in their state restoration

Oh I thought the developer would have to restore GoogleSignIn, and state restoration only supports value types. If the dart part of GoogleSignIn doesn't keep any secret state itself then that makes sense.

LongCatIsLooong · 2025-06-03T17:00:14Z

packages/google_sign_in/google_sign_in/example/lib/main.dart

+  Future<void> _handleAuthenticationEvent(
+      GoogleSignInAuthenticationEvent event) async {
+    // #docregion CheckAuthorization
+    GoogleSignInAccount? user;


uber nit, consider making user and authorization final if possible?

Made user final. Making authorization final would require adding an else { authorization = null; } or restructuring to use a ternary in the assignment or using patterns, all of which would make the example more complicated for the README snippet.

Does this work?

final authorization = await user?.authorizationClient.authorizationForScopes(scopes);

LongCatIsLooong · 2025-06-03T17:23:16Z

packages/google_sign_in/google_sign_in/lib/google_sign_in.dart

  ///
-  /// Returned Future resolves to an instance of [GoogleSignInAccount] for a
-  /// successful sign in or `null` in case sign in process was aborted.
+  /// If this returns false, [authenticate] will throw an UnsupportedError if


nit: missing backticks / square brackets around UnsupportedError?

LongCatIsLooong · 2025-06-03T17:23:30Z

packages/google_sign_in/google_sign_in/lib/google_sign_in.dart

-  /// successful sign in or `null` in case sign in process was aborted.
+  /// If this returns false, [authenticate] will throw an UnsupportedError if
+  /// called. See the platform-specific documentation for the package to
+  /// determine how authentication his handled. For instance, the platform may


LongCatIsLooong · 2025-06-03T17:32:18Z

packages/google_sign_in/google_sign_in/lib/src/event_types.dart

+
+/// A base class for authentication event streams.
+@immutable
+sealed class GoogleSignInAuthenticationEvent {


Are these classes needed? It seems the sealed type is a glorified GoogleSignInAccount?.

Originally there were three subclasses, but exceptions moved into onError; now we could make them GoogleSignInAccount?.

It would make things less self-documenting though. It's non-obvious that getting null as an authenticationEvent means "the user signed out". Is that worth the slightly easier usage?

I was thinking maybe we can avoid introducing new classes by using typedef or extension types. I played with that idea but found the resulting code harder to read (the user code would still be the same though). So never mind.

LongCatIsLooong · 2025-06-03T17:39:56Z

...gle_sign_in_ios/darwin/google_sign_in_ios/Sources/google_sign_in_ios/FLTGoogleSignInPlugin.m


 // The plugin registrar, for querying views.
-@property(strong, nonnull) id<FlutterPluginRegistrar> registrar;
+@property(nonatomic) id<FlutterPluginRegistrar> registrar;


is this still nonnull?

Yes, I must have deleted that by mistake when removing strong. Re-added.

LongCatIsLooong · 2025-06-03T18:07:18Z

...gle_sign_in_ios/darwin/google_sign_in_ios/Sources/google_sign_in_ios/FLTGoogleSignInPlugin.m

-       completion:(nullable void (^)(GIDSignInResult *_Nullable signInResult,
-                                     NSError *_Nullable error))completion {
-  GIDGoogleUser *currentUser = self.signIn.currentUser;
+    forGoogleSignInUser:(GIDGoogleUser *)user


I assume the user argument is not nullable, otherwise it's failing silently?

Yes. I've added some more nullability annotations for the private methods; in past projects we didn't annotate implementation files in general, but there's no reason not to here, and since Obj-C nullability is basically just documentation anyway we may as well express it (as we generally do with our newer Java plugin code).

LongCatIsLooong · 2025-06-03T18:09:50Z

...gle_sign_in_ios/darwin/google_sign_in_ios/Sources/google_sign_in_ios/FLTGoogleSignInPlugin.m

  }];
 }

+- (void)addScopes:(nonnull NSArray<NSString *> *)scopes
+          forUser:(NSString *)userId


can userId be null?

Nope, added annotation.

LongCatIsLooong · 2025-06-03T18:18:03Z

...gle_sign_in_ios/darwin/google_sign_in_ios/Sources/google_sign_in_ios/FLTGoogleSignInPlugin.m

 - (void)signOutWithError:(FlutterError *_Nullable *_Nonnull)error {
  [self.signIn signOut];
+  [self.usersByIdentifier removeAllObjects];


The signOut method seems to only sign out the current user: https://developers.google.com/identity/sign-in/ios/reference/Classes/GIDSignIn

Why do we have to remove everything in the dictionary? If refreshedAuthorizationTokensForUser gets called for a different user (is that possible`?) the app would get an error it seems?

The signOut method seems to only sign out the current user

That's true, but unlike the other platforms, Google Sign In for iOS bakes in the idea of a single current user in various places.

Why do we have to remove everything in the dictionary? If refreshedAuthorizationTokensForUser gets called for a different user (is that possible`?) the app would get an error it seems?

I was going to say it would anyway, but it looks like valid tokens would still be returned. Adding scopes, on the other hand will just fail. The underlying SDK API is a little strange in that it will potentially vend multiple user objects, but some operations will fail on all but one (and as a result, our API has the same behavior on iOS).

But it looks like we'll actually get better behavior by never clearing usersByIdentifier, so calls will continue to use the underlying SDK user objects if they have ever been available, and we can leave it to the SDK to work or not depending on its implementation details. User objects should be pretty lightweight, and in practice I expect it will be rare to make more than one anyway.

I've replaced this with a comment explaining why we're not removing anything from the dictionary.

LongCatIsLooong

The changes SGTM but I don't see a new commit?

LongCatIsLooong · 2025-06-04T23:09:27Z

packages/google_sign_in/google_sign_in/README.md


 ### Requesting more scopes when needed

 If an app determines that the user hasn't granted the scopes it requires, it
-should initiate an Authorization request. (Remember that in the web platform,
-this request **must be initiated from an user interaction**, like a button press).
+should initiate an Authorization request. On some platforms, such as web,


Sounds good (I don't see a new commit tho).

LongCatIsLooong · 2025-06-04T23:11:59Z

packages/google_sign_in/google_sign_in/example/lib/main.dart

-      }
-// #enddocregion CanAccessScopes
+    // #docregion Setup
+    final GoogleSignIn signIn = GoogleSignIn.instance;


include auth state in their state restoration

Oh I thought the developer would have to restore GoogleSignIn, and state restoration only supports value types. If the dart part of GoogleSignIn doesn't keep any secret state itself then that makes sense.

LongCatIsLooong · 2025-06-04T23:19:48Z

packages/google_sign_in/google_sign_in/example/lib/main.dart

+  Future<void> _handleAuthenticationEvent(
+      GoogleSignInAuthenticationEvent event) async {
+    // #docregion CheckAuthorization
+    GoogleSignInAccount? user;


Does this work?

final authorization = await user?.authorizationClient.authorizationForScopes(scopes);

LongCatIsLooong · 2025-06-04T23:39:38Z

packages/google_sign_in/google_sign_in/lib/src/event_types.dart

+
+/// A base class for authentication event streams.
+@immutable
+sealed class GoogleSignInAuthenticationEvent {


I was thinking maybe we can avoid introducing new classes by using typedef or extension types. I played with that idea but found the resulting code harder to read (the user code would still be the same though). So never mind.

stuartmorgan-g · 2025-06-05T12:26:02Z

The changes SGTM but I don't see a new commit?

Oops, I didn't notice that the push failed (I forgot I'd done a merge from main via the GitHub UI).

stuartmorgan-g · 2025-06-05T14:17:20Z

Does this work?

final authorization = await user?.authorizationClient.authorizationForScopes(scopes);

🤦🏻 Yes, that's much simpler.

(I can't reply inline to that comment, I think because I force-pushed so the commit it was on no longer exists.)

stuartmorgan-g added 20 commits May 15, 2025 11:11

Initial PoC using CredentialManager

432a627

Pathify everything for local development

df1cf87

Remove method channel implementation

6a1ec7c

First pass rework of interface, impls, and app-facing API

49342c5

Also reworks app-facing package example app for testing.

Add nonce support

eba7a8b

Initial README updates and migration guide

f3d472f

Rework Android calls to match recommended practice

728a4f9

Synthesize sign-out event for disconnect

c165834

platform interface tests

dba0f3e

Simplify Android Pigeon API

83c7b1d

Android Dart unit tests

82c0530

iOS Dart unit tests

4123b18

Web Dart 'unit' tests, and fix lightweight auth return

165fb78

Update example apps

eda66bb

Update native unit tests, fix an Obj-C selector name

21635a0

Update to recent 1.5 release

39b7505

Android native unit tests

07fe543

README, CHANGELOG, and version updates

e6c9f62

App-facing Dart tests

90a63aa

Revert unrelated Xcode project changes

816f614

stuartmorgan-g requested review from LongCatIsLooong, cbracken, camsim99 and ditman as code owners May 16, 2025 17:54

github-actions bot added p: extension_google_sign_in_as_googleapis_auth p: google_sign_in platform-android platform-ios platform-macos platform-web labels May 16, 2025

stuartmorgan-g added 6 commits May 28, 2025 13:35

Remove unused People code

b44ff39

Restructure options slightly

8640443

Add TODO issue link

86a7a1d

Add activity lifecycle tests

4fb7fea

Add authorize param tests

563680c

Test safety check, better README

dab117f

stuartmorgan-g requested a review from ash2moon as a code owner May 29, 2025 02:07

stuartmorgan-g requested review from camsim99 and ditman May 29, 2025 02:07

stuartmorgan-g added 4 commits May 29, 2025 08:25

Analyzer

81f59f7

Java autoformat

6b76be0

excerpt update

9817325

Add stack traces to stream errors

20a8fc5

stuartmorgan-g added the triage-ios Should be looked at in iOS triage label May 29, 2025

stuartmorgan-g added 3 commits May 29, 2025 11:24

Handle emulators without sign-in support

d6bd8bc

Add another missing stack

6766860

Rework the stream tests to make wasm happy

8ad0051

camsim99 approved these changes Jun 2, 2025

View reviewed changes

stuartmorgan-g requested a review from bparrishMines June 3, 2025 15:00

LongCatIsLooong reviewed Jun 3, 2025

View reviewed changes

stuartmorgan-g added 3 commits June 3, 2025 16:42

Merge branch 'main' into google-sign-in-authn-authz-redesign

98e55b2

Minor iOS review fixes

f36a6c8

Add authorizationRequiresUserInteraction

2823a54

stuartmorgan-g requested a review from LongCatIsLooong June 4, 2025 20:56

LongCatIsLooong reviewed Jun 4, 2025

View reviewed changes

stuartmorgan-g force-pushed the google-sign-in-authn-authz-redesign branch from 9fe4f32 to 2823a54 Compare June 5, 2025 12:25

[google_sign_in] Redesign API for current identity SDKs #9267

Are you sure you want to change the base?

[google_sign_in] Redesign API for current identity SDKs #9267

Conversation

stuartmorgan-g commented May 16, 2025

Pre-Review Checklist

Footnotes

Uh oh!

camsim99 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stuartmorgan-g commented Jun 3, 2025

Uh oh!

stuartmorgan-g commented Jun 3, 2025

Uh oh!

LongCatIsLooong left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LongCatIsLooong left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment