[google_sign_in_web] Migrate from Google Sign-In JavaScript Platform Library to Google Identity Services

[jmagman]

---

TL;DR:

Note

• Fix released in package: google_sign_in: ^6.0.0.
• Read the migration notes in the google_sign_in_web README.

---

Original issue below:

Internal: b/233812803

Internal: b/259309242

Google Sign-In JavaScript Platform Library used by the google_sign_in web plugin will be discontinued on March 31, 2023.

It is being replaced by Google Identity Services

https://github.com/flutter/plugins/blob/b548ae18646d1725a8e1f004c26bf42e4d362aa8/packages/google_sign_in/google_sign_in_web/lib/google_sign_in_web.dart#L24

See also

• [google_sign_in] web implemented uses deprecated APIs #101004

[jmagman]

\cc @ditman

[Levi-Lesches]

See also #82980

[ditman]

Thanks for reporting! I'll take a look at this ASAP; apologies for the nagging emails, I wasn't aware that this migration was going to happen or that we'd send out emails to eeeevery user of the plugin :)

Speaking of the email, here's the full text we all received (included for SEO purposes on this issue :P)

Google Developers

One or more of your web applications uses the legacy Google Sign-In JavaScript library. Please migrate your project(s) to the new Google Identity Services SDK before March 31, 2023.

Hello Google Developer,

As announced earlier this month, the legacy Google Sign-In web solution will no longer be supported after March 31, 2023. You are receiving this message because one or more of your web applications uses the legacy Google Sign-In web solution.

We’re writing to let you know that migration to the new Google Identity Services - our new family of Identity APIs that consolidate multiple identity offerings under one software development kit (SDK) - will be necessary to sign in users using their Google Account to your platform, after that date. The SDK will use the new Sign In With Google client library.

What do I need to know?

To help you find out which of your web apps or environments are affected, we’re sharing a list of your client ID(s) that use the legacy Google Sign-In web solution. This list should help you evaluate user impact and prioritize the migration work more efficiently:

App Name	client ID
Your App Name	00000000-y0urg00gl3s1gn1n4p1k3y.apps.googleusercontent.com

What do I need to do?

At your earliest convenience, migrate to the new Google Identity Services by following the migration guide.

How can I find more information or share feedback?

Be sure to read through the Sign-In With Google resources guide. If you have migration specific feedback to share, send an email to [email protected].

Sincerely,

The Google Identity Services team

Luckily we have until 2023 to get this done ;P

Since google_sign_in is federated, we can start a new package for web that uses the new SDK. People will be able to test the new plugin while it's being developed, and once the new plugin is ready and tested, we can just change the endorsement to the new one.

I am not sure if we want to use this opportunity to rewrite the core plugin (a completely new platform interface, etc...). Any ideas @jmagman @blasten @stuartmorgan ?

[stuartmorgan-g]

I am not sure if we want to use this opportunity to rewrite the core plugin (a completely new platform interface, etc...). Any ideas @jmagman @blasten @stuartmorgan ?

Is this using the new two-phase flow like the latest iOS SDK? If so, then we should seriously consider a set of breaking changes to all the interfaces across platforms to pick up that model. (We're waiting a bit to see what happens with the feedback that the new iOS SDK has received though in case anything changes as a result.)

[ditman]

I'm going to try and follow-up with somebody in the Google Identity Services team for a little bit more insight into this matter, and to see if they have any preference/suggestion in the future direction of the plugin API.

[cybex-dev]

@ditman looking forward to this update, got a rough eta?

[Zujaj]

Any update regarding Flutter Web, because the Google One-Tap Sign In package works only for Android.

[ditman]

@cybex-dev not yet, but I brought this up again to the team so it gets prioritized.

@Zujaj that package is developed by a third party and we don't support it. Find its repository here.

[kmeljko]

any news about this issue @ditman ?

[ditman]

No news, I'd personally would like to wrap this up by Q3 2022 so there's one Q for user testing/emergency fixes, and then we can release this at the end of Q4 2022 (right before the migration must happen)

[ditman]

See some interesting comments in the related ticket above:

@brdaugherty commented 4 days ago
...
Not mentioned in the above resources is the deprecation of the gapi.auth2 module found in the Google API Client Library for JavaScript. This module is shared with Google Sign-in platform.js library. The deprecation affects both. It is very likely you've reviewed the developer migration guides already, but for completeness: for user sign-in and for authorization.

We'll need a new JS-interop layer to go with the plugin.

Also, since this seems to only affect web, we'll try to implement the already existing plugin API with the new JS API. Docs. It seems that a migration to the new API with ux_mode=popup should be fairly straightforward.

[ditman]

/cc @kevmoo any chance we could use package:googleapis (or googleapis_auth?) as the JS-interop layer for this new google.accounts JS API?

[kevmoo]

@ditman – perhaps? Tha browser auth code there is pretty old. I've done some cleanup there, but it's pretty old.

In general, fewer Dart implementations of this logic would be better!

[ditman]

Immediate next steps to mitigate:

Beginning April 30th, 2022 new applications must use the Google Identity Services library, existing apps may continue using the Platform Library until the deprecation date.

We'll do a small modification to the google_sign_in plugin suggested by @brdaugherty today so new applications can continue using the plugin after April 30th 2022.

[ditman]

We'll do a small modification to the google_sign_in plugin suggested by @brdaugherty today so new applications can continue using the plugin after April 30th 2022.

This has been published as package:google_sign_in_web v0.10.1.

[ditman]

On page load a signInSilently() got triggered to sign-in the user in the background if he already signed-in manually before. And on the login button the signIn() will get triggered manually. Both of these scenario's used to fire an event in the onCurrentUserChanged listener, but currently only signIn does that.

@ramonvermeulen That is correct. This happened because the former SDK did authentication+authorization in one step, but now they're two separated clients.

On signInSilently, only authentication happens, so if the plugin gave you an "authenticated but not authorized" user, all your API requests would start failing.

Only when the user is fully authenticated and authorized (after signIn), you get a signed in notification.

silentUserLogin() async {
  _googleSignIn.onCurrentUserChanged.listen((GoogleSignInAccount? account) {
    print("user changed"); // never gets called
  });
  await _googleSignIn.signInSilently();
  await _googleSignIn.requestScopes(_googleSignIn.scopes);
}

You cannot signIn (or requestScopes) without user interaction, because those two methods always trigger opening a popup. I think this previous answer may be helpful in your case. TL;DR:

1. Try to signInSilently when you build your page. This is probably the code that you already have. That will show the One Tap UX in your page, and if the user agrees, you'll have user authentication information (idToken).
2. You must signIn or requestScopes in an interactive bit of your app (a button), so users click and the browser allows the pop-up to open. Once this is done, you'll get the authorizationToken.

(Your code is probably already doing 1 and 2 above)

Preferably I want to let the user signIn and request scopes once, and the next times the user revisits the application signInSilently will handle most of it in the background.

That is not going to be possible moving forward, since the new SDK is separating authentication (user ID) from authorization (user permissions). However, if the user has never signed out of your application (or their tokens have expired), their sign-in will be almost automatic (the popup will show up, but will close automatically without users having to do anything extra).

The last line felt a bit weird since I have the following in my index.html

Don't worry about the last line. That's a trick that the new SDK is attempting to do to be "less breaking" with the users of those libraries. In fact, you should not need any script tag for google authentication to work. Check our super-simple example app.

The biggest issue that you might encounter is that API requests from your app might start failing, and users need to re-authorize access to the scopes. The mechanics of authentication should remain the same/similar.

[ramonvermeulen]

On page load a signInSilently() got triggered to sign-in the user in the background if he already signed-in manually before. And on the login button the signIn() will get triggered manually. Both of these scenario's used to fire an event in the onCurrentUserChanged listener, but currently only signIn does that.

@ramonvermeulen That is correct. This happened because the former SDK did authentication+authorization in one step, but now they're two separated clients.

On signInSilently, only authentication happens, so if the plugin gave you an "authenticated but not authorized" user, all your API requests would start failing.

Only when the user is fully authenticated and authorized (after signIn), you get a signed in notification.

silentUserLogin() async {
  _googleSignIn.onCurrentUserChanged.listen((GoogleSignInAccount? account) {
    print("user changed"); // never gets called
  });
  await _googleSignIn.signInSilently();
  await _googleSignIn.requestScopes(_googleSignIn.scopes);
}

You cannot signIn (or requestScopes) without user interaction, because those two methods always trigger opening a popup. I think this previous answer may be helpful in your case. TL;DR:

1. Try to signInSilently when you build your page. This is probably the code that you already have. That will show the One Tap UX in your page, and if the user agrees, you'll have user authentication information (idToken).
2. You must signIn or requestScopes in an interactive bit of your app (a button), so users click and the browser allows the pop-up to open. Once this is done, you'll get the authorizationToken.

(Your code is probably already doing 1 and 2 above)

Preferably I want to let the user signIn and request scopes once, and the next times the user revisits the application signInSilently will handle most of it in the background.

That is not going to be possible moving forward, since the new SDK is separating authentication (user ID) from authorization (user permissions). However, if the user has never signed out of your application (or their tokens have expired), their sign-in will be almost automatic (the popup will show up, but will close automatically without users having to do anything extra).

The last line felt a bit weird since I have the following in my index.html

Don't worry about the last line. That's a trick that the new SDK is attempting to do to be "less breaking" with the users of those libraries. In fact, you should not need any script tag for google authentication to work. Check our super-simple example app.

The biggest issue that you might encounter is that API requests from your app might start failing, and users need to re-authorize access to the scopes. The mechanics of authentication should remain the same/similar.

@ditman Thanks a lot for your clarification! With this information I think I need to redesign the flow in the application a little bit to make this work.

In my case onCurrentUserChanged still does not get triggered after calling requestScopes (manually) when the user is already signed-in with signInSilently. I only manage to get the event triggered with the signIn function. I changed my login function (triggered on manual click) to the following, and signInSilently got called on page load with an event listener on onCurrentUserChanged:

  Future<void> logIn() async {
    try {
      var signedIn = await _googleSignIn.isSignedIn();
      if (signedIn) {
        await _googleSignIn.requestScopes(_googleSignIn.scopes); // does just scopes
      } else {
        await _googleSignIn.signIn(); // does sign-in + scopes
      }
    } catch (error) {
      throw LogInFailure.fromMessage(error.toString());
    }
  }

I can always use signIn instead of requestScopes, but then the whole signInSilently part and one-tap pop-up feels redundant since you have to call signIn anyways?

In my opinion it feels really unnatural that after signInSilently and the GIS pop-up being showed, the user still has to manually click on a button to trigger another pop-up (e.g. requestScopes) to request the authorization scopes. Out of an user perspective if the GIS pop-up is being showed with a chevron the user has the feeling of being signed in. It's quite weird to then have to click on another button to trigger another pop-up to retrieve the right scopes, before being "actually" signed-in into the application. I mean technically you can define the first part as being "signed-in", however in a lot of applications you need additional scopes to be able to actually do something within the application such as calling external API's. In my case it is an application totally build around Google Cloud Search API for which it needs additional scopes.

Out of an implementation perspective I totally get it, they are two different clients one for authentication (GIS one-tap part) and one for authorization (old style pop-up). But for my application it feels more like a step back rather than a step forward.

P.s.

I will clone and test the example app to hopefully get a bit wiser

[ditman]

I can always use signIn instead of requestScopes, but then the whole signInSilently part and one-tap pop-up feels redundant since you have to call signIn anyways?

@ramonvermeulen in your case, maybe it's simpler to just stop doing signInSilently on the web, and just use signIn when the user clicks the sign in button? Wouldn't this be the same/similar that your current app does when signInSilently returns a null idToken in the current implementation (?).

About signIn and requestScopes, I don't think you need to over-think this too much. Use signIn. If you still use signInSilently, and users have consented to it, the popup will go straight to the requestScopes part. If the user hasn't completed signInSilently (they're not authenticated in the browser, or they aborted the process), signIn will sign them in, and then requestScopes.

The code of the new plugin does what it does to maximize the compatibility with the previous code, without you having to change much about the sign-in flow (for more details, pls look at the full README!)

it feels really unnatural that after signInSilently and the GIS pop-up being showed, the user still has to manually click on a button to trigger another pop-up (e.g. requestScopes) to request the authorization scopes. [...] in a lot of applications you need additional scopes to be able to actually do something within the application such as calling external API's. [...] for my application it feels more like a step back rather than a step forward.

I agree. This plugin is just another user of the new GIS SDK and had very little input on its design. In fact, the way this unfolded has us thinking about the future of the Google Sign In plugin(s) as a whole.

I can explain why this is moving to a "two step" process, though! In the near future, idTokens may come straight from the user's web browser rather than Google; for example see FedCM, and FIDO2. In those cases, the Authentication is handled by the browser, locally, but the Authorization process would still need to call the remote service for permissions.

Anyway, thanks for giving this a shot, I hope you manage to work around the quirks of the new SDKs!

[ramonvermeulen]

I can always use signIn instead of requestScopes, but then the whole signInSilently part and one-tap pop-up feels redundant since you have to call signIn anyways?

@ramonvermeulen in your case, maybe it's simpler to just stop doing signInSilently on the web, and just use signIn when the user clicks the sign in button? Wouldn't this be the same/similar that your current app does when signInSilently returns a null idToken in the current implementation (?).

About signIn and requestScopes, I don't think you need to over-think this too much. Use signIn. If you still use signInSilently, and users have consented to it, the popup will go straight to the requestScopes part. If the user hasn't completed signInSilently (they're not authenticated in the browser, or they aborted the process), signIn will sign them in, and then requestScopes.

The code of the new plugin does what it does to maximize the compatibility with the previous code, without you having to change much about the sign-in flow (for more details, pls look at the full README!)

it feels really unnatural that after signInSilently and the GIS pop-up being showed, the user still has to manually click on a button to trigger another pop-up (e.g. requestScopes) to request the authorization scopes. [...] in a lot of applications you need additional scopes to be able to actually do something within the application such as calling external API's. [...] for my application it feels more like a step back rather than a step forward.

I agree. This plugin is just another user of the new GIS SDK and had very little input on its design. In fact, the way this unfolded has us thinking about the future of the Google Sign In plugin(s) as a whole.

I can explain why this is moving to a "two step" process, though! In the near future, idTokens may come straight from the user's web browser rather than Google; for example see FedCM, and FIDO2. In those cases, the Authentication is handled by the browser, locally, but the Authorization process would still need to call the remote service for permissions.

Anyway, thanks for giving this a shot, I hope you manage to work around the quirks of the new SDKs!

@ditman Thanks for the explanation! I eventually got it all working in the application, had to dive a bit into how to persist state with bloc using hydrated bloc and make some structural changes to the application. I save the authHeaders in state now, and log the user out if I get a 403 back from one of the google APIs. The accessToken has a lifetime of 1 hour, so after 1 hour the user has to manually sign in again. I haven't seen a mechanism to refresh the accessToken yet (can't find a refreshToken in GoogleSignInAuthentication for example), or change the lifetime of the accessToken. (Maybe I'm missing something here, if one of these is possible I would be even more happy 😄 but referring to the docs I guess extending the lifetime is not possible)

I haven't heard of the FedCM and FIDO2 concepts before. Thanks for referring to it, makes more sense now why google is separating authentication and authorization to different APIs.

[ditman]

I haven't seen a mechanism to refresh the accessToken yet (can't find a refreshToken in GoogleSignInAuthentication for example), or change the lifetime of the accessToken. (Maybe I'm missing something here, if one of these is possible I would be even more happy 😄 but referring to the docs I guess extending the lifetime is not possible)

@ramonvermeulen This is not possible from the client-side anymore, if you want to extend a users' session, they need to re-authorize the scopes.

The only way that I'm aware of that you get a renew token and all that jazz is if when you use the "Authorization Code" model, which then you use from your server-side to do requests to Google on your users' behalf, behind the scenes.

Then your users access your backend (and not Google's) where you're supposed to have all the data they need.

I eventually got it all working in the application, had to dive a bit into how to persist state with bloc using hydrated bloc and make some structural changes to the application. I save the authHeaders in state now, and log the user out if I get a 403 back from one of the google APIs.

I think a blog post about this, if you have the energy to write it, would be very beneficial to the community. I can't handle all the integrations with all the possible state management solutions, but we can have links to blog posts describing solutions for the most common architectures!

[ditman]

The PR has been reviewed and labeled as autosubmit, it'll land into the repo as soon as it's ready to accept new changes.

[ditman]

Reopening this until we update the core plugin to use the new version!

The new version of the web package (google_sign_in_web: ^0.11.0) is now available on pub.dev:

https://pub.dev/packages/google_sign_in_web

I'll update google_sign_in to endorse the new version of the web package shortly.

[ramonvermeulen]

I haven't seen a mechanism to refresh the accessToken yet (can't find a refreshToken in GoogleSignInAuthentication for example), or change the lifetime of the accessToken. (Maybe I'm missing something here, if one of these is possible I would be even more happy smile but referring to the docs I guess extending the lifetime is not possible)

@ramonvermeulen This is not possible from the client-side anymore, if you want to extend a users' session, they need to re-authorize the scopes.

The only way that I'm aware of that you get a renew token and all that jazz is if when you use the "Authorization Code" model, which then you use from your server-side to do requests to Google on your users' behalf, behind the scenes.

Then your users access your backend (and not Google's) where you're supposed to have all the data they need.

I eventually got it all working in the application, had to dive a bit into how to persist state with bloc using hydrated bloc and make some structural changes to the application. I save the authHeaders in state now, and log the user out if I get a 403 back from one of the google APIs.

I think a blog post about this, if you have the energy to write it, would be very beneficial to the community. I can't handle all the integrations with all the possible state management solutions, but we can have links to blog posts describing solutions for the most common architectures!

Thanks for the information, also nice job on the Migrating to v0.11 section in the readme, explains everything really well in my opinion.

I see, in my case we don't have our own server-side "back-end" for this app. It's just a client calling Google API's for authentication / authorization, and then fetching search results from the Google Cloud Search API (which is basically the back-end). But I don't think it will be that big of a problem that an user has to re-authorize after 1 hour of inactivity, was just wondering if there were other options.

Unfortunately I'm quite packed with work at the moment, so I don't have a lot of time to write a blog post. However, for people reading this and facing the same issues and are already using flutter_bloc as state management solution within their application. Be sure to take a look at hydrated_bloc which is the library I used to persist the bloc state, for instance you can store the authHeaders persistently so a user can stay "signed-in" with the required scopes for up to one hour.

[ditman]

in my case we don't have our own server-side "back-end" for this app. It's just a client calling Google API's for authentication / authorization, and then fetching search results from the Google Cloud Search API (which is basically the back-end)

@ramonvermeulen yes, this is the case of many people too, you're not alone :)

I don't think it will be that big of a problem that an user has to re-authorize after 1 hour of inactivity

I think users have to re-authorize after 1 hour (even if they're being very busy with your app!)

I'm quite packed with work at the moment, so I don't have a lot of time to write a blog post.

Again, thanks for giving this a test, checking the documentation and everything! Please, feel no pressure about the blog post at all! It's possible that others will fill the gaps. IMO people finding this issue and knowing that their migration "is possible" is quite a good start!

[TimYusR]

Hi! @ditman
I have a problem with the new google_sign_in version 6.0.0 on the web.

I call signIn() which returns GoogleSignInAccount. Then I call authentication and hope to get an idToken for my backend as it was in the previous version of the package, but the idToken is null, instead, I have an accessToken which the backend can't exchange on our access token.

Here's my piece of code

  Future<String> signInWithGoogleIdToken() async {
    GoogleSignInAccount? account;

    try {
      account = await googleSignIn.signIn();
    } catch (e) {
      _catchSignInError(e);
    }

    final authentication = await account?.authentication;

    return authentication?.idToken ?? '';
  }

I've read the previous conversation here and think that idToken shouldn't be null.
I suppose this is the working code and it's similar to mine (second one).

I will appreciate it if you can give me some advice on what could happen wrong 🙏

[ditman]

I call signIn() [...], but the idToken is null

@TimYusR, @scrfrk, @NickelGit, @Silipok, @ruslanislan, @JavasquirtDeveloper, @tuanvumaihuynh you're correct. Since signIn now uses the Oauth implicit flow to authenticate and authorize users, an idToken is not being returned there.

If you need the idToken, make sure to call signInSilently when you build your page to give an opportunity to the OneTap UX to grab the idToken (if the user wants to give it to you).

Here's the relevant information about your use case:

https://pub.dev/packages/google_sign_in_web#idtoken-is-null-in-the-googlesigninaccount-object-after-signin

(Since we have received a bunch of feedback regarding this, I'm going to report the lack of an idToken on the Oauth flows as a bug feature request to the GIS team //cc @brdaugherty -> b/270203049).

[TimYusR]

So I need to call signInSilently even if I don't need that. It seems a little bit awkward 😅

@ditman Thanks!

(Since we have received a bunch of feedback regarding this, I'm going to report the lack of an idToken on the Oauth flows as a bug feature request to the GIS team //cc @brdaugherty -> b/270203049).

[ditman]

It seems a little bit awkward 😅

It is, however it was required to make the new SDK behave similarly to the old one to ease the migration of everybody!

[pldelattre]

A few comments after testing:

1/ using googleSignIn.signIn() works well with firebase auth in the cloud but will break firebase auth emulator since it expects idToken. Error is the following :

firebase_auth/the-auth-emulator-only-support-sign-in-with-google.com-using-id-token,-not-access-token.-please-update-your-code-to-use-id-token

2/ and when using signInSilently followed by signIn as in the following code :

Future googleLogin() async {
    try {
      await googleSignIn.signInSilently();
      final googleUser = await googleSignIn.signIn();
      if (googleUser == null) return;

      final googleAuth = await googleUser.authentication;

      final credential = GoogleAuthProvider.credential(
        accessToken: googleAuth.accessToken,
        idToken: googleAuth.idToken,
      );

      await FirebaseAuth.instance.signInWithCredential(credential);
    } catch (e) {
      debugPrint(e.toString());
    }
  }

It works well on a chrome session that already knows my google account, however it fails in an incognito window.
In the incognito window, first click on the login button open the signIn popup dialog (and I suppose it fails to get the idToken because signInSilently failed). However, I would have expected that a retry on the login button would work and instead I get the following error :

@ditman

[ditman]

"I would have expected that a retry on the login button would work"

@pldelattre It doesn't work, because the retry needs to be done by signInSilently. You should probably refresh the incognito window after sign-in, to let the signInSilently process to work?

[pldelattre]

"I would have expected that a retry on the login button would work"

@pldelattre It doesn't work, because the retry needs to be done by signInSilently. You should probably refresh the incognito window after sign-in, to let the signInSilently process to work?

If you look at my googleLogin() function in the message above which is the function I call with the button, you can see that the first line is calling signInSilently and this is why I expected a retry on the button to work. Unfortunately, it does not.

[ditman]

the first line is calling signInSilently and this is why I expected a retry on the button to work. Unfortunately, it does not.

Please, check the JS Console of the browser (in development mode) for logging, it'll let you know if the OneTap UX decided to not show up for any reason. There's a few reasons why the "One Tap UX" may not show, it's smart. Please, use signInSilently as advised: when you build your pages, and not as part as your "signIn" button implementation.

There's also an internal bug that I'm trying to get solved to make this much simpler for everybody; as mentioned here.

[c-seeger]

With the current solution it feels a bit strange, since google silent login will always be triggered on my LoginPage (using it as stated in the example within the initState). My LoginPage contains multiple login options not only google, so google should only be triggered to make any call to google services once the user decides to use it for login but not in advance.

[ditman]

My LoginPage contains multiple login options not only google, so google should only be triggered to make any call to google services once the user decides to use it for login but not in advance.

@c-seeger yes, you're right. I guess your Login page is similar to a "logo tower" with a bunch of login options. In that case, GSI recommends this:

• Display the Sign In With Google button

This is a missing feature of the current google_sign_in_web. Could you create a new issue so we can discuss its implementation separately from the more general plugin? (I'm afraid this would be a web-only feature)

(There's also the problem that users authenticating there would still not authorize scopes however!)

[ditman]

Hello all who must have an idToken!

I'm currently implementing the "Google Sign In Button" flow for the web. Please, follow the progress in the corresponding places:

• The issue: [google_sign_in_web] Display Sign In With Google button #121781
• The WIP: [google_sign_in] Adds "Button" Sign In for Web. packages#3461

The PR adds the "Google Sign In Button" as a Flutter for Web Widget, so Web apps can use that instead of the programmatic signIn code.

It also adds a canAccessScopes method so the app can check if a logged-in user still has permissions to access all the scopes that are needed.

Also also: updates the example code to see all the new changes "in action".

(PS: I think we should stop updating this issue. Let's continue the conversation in the issues/PRs that are being actively worked on, or on new ones for anything new that might show up. Thanks for reading!)

[rekire]

hey @ramonvermeulen how did you fix your issue with [GSI_LOGGER-TOKEN_CLIENT]: The OAuth token was not passed to gapi.client, since the gapi.client library is not loaded in your page.? just using signIn() instead of signInSilently() doesn't work for me

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.