The web implementation of google_sign_in
This package is endorsed, which means you can simply use google_sign_in normally. This package will be automatically included in your app when you do, so you do not need to add it to your pubspec.yaml.
However, if you import this package to use any of its APIs directly, you should add it to your pubspec.yaml as usual.
For example, you need to import this package directly if you plan to use the web-only Widget renderButton() method.
First, go through the instructions here to create your Google Sign-In OAuth client ID.
On your web/index.html file, add the following meta tag, somewhere in the head of the document:
<meta name="google-signin-client_id" content="YOUR_GOOGLE_SIGN_IN_OAUTH_CLIENT_ID.apps.googleusercontent.com">
For this client to work correctly, the last step is to configure the Authorized JavaScript origins, which identify the domains from which your application can send API requests. When in local development, this is normally localhost and some port.
You can do this by:
For local development, you must add two localhost entries:
http://localhost andhttp://localhost:7357 (or any port that is free in your machine)Normally flutter run starts in a random port. In the case where you need to deal with authentication like the above, that's not the most appropriate behavior.
You can tell flutter run to listen for requests in a specific host and port with the following:
flutter run -d chrome --web-hostname localhost --web-port 7357
This implementation returns false for supportsAuthentication, and will throw if authenticate is called. This is because the Google Identity Services (GIS) SDK only allows signing in using UI provided by the SDK.
On the web, instead of providing custom UI that calls authenticate, you should display the Widget returned by renderButton (from web_only.dart), and listen to authenticationEvents to know when the user has signed in.
The GIS SDK does not renew authentication sessions. Once the token expires (after 3600 seconds), if you need to use the idToken again you must trigger a new authentication flow. In most cases, you should use the idToken immediately after authentication, and track sign-in state at the application level, or via a separate server backend.
See Migrating from Google Sign-In for information about the differences between authentication in the GIS SDK and the SDK used in older versions of this plugin.
Since the GIS SDK does not manage user sessions anymore, apps that relied on this feature might break. If long-lived sessions are required, consider using some user authentication system that supports Google Sign In as a federated Authentication provider, like Firebase Auth.
The GIS SDK does not renew authorization sessions. Once the token expires (after 3600 seconds), API requests will begin to fail, and you must re-request user authorization. For example:
401: Missing or invalid access token.403: Expired access token.See the “Integration considerations > UX separation for authentication and authorization guide” in the official GIS SDK documentation for more information about this.
See Migrate to Google Identity Services for information about the differences between authentication in the GIS SDK and the SDK used in older versions of this plugin.