A Flutter plugin for Google Sign In.
Android | iOS | Web | |
---|---|---|---|
Support | SDK 16+ | iOS 11+ | Any |
To access Google Sign-In, you'll need to make sure to register your application.
You don‘t need to include the google-services.json file in your app unless you are using Google services that require it. You do need to enable the OAuth APIs that you want, using the Google Cloud Platform API manager. For example, if you want to mimic the behavior of the Google Sign-In sample app, you’ll need to enable the Google People API.
Make sure you've filled out all required fields in the console for OAuth consent screen. Otherwise, you may encounter APIException
errors.
Please see instructions on integrating Google Sign-In for iOS.
Note that according to https://developer.apple.com/sign-in-with-apple/get-started, starting June 30, 2020, apps that use login services must also offer a “Sign in with Apple” option when submitting to the Apple App Store.
Consider also using an Apple sign in plugin from pub.dev.
The Flutter Favorite sign_in_with_apple plugin could be an option.
The new SDK used by the web has fully separated Authentication from Authorization, so signIn
and signInSilently
no longer authorize OAuth scopes
.
Flutter apps must be able to detect what scopes have been granted by their users, and if the grants are still valid.
Read below about Working with scopes, and incremental authorization for general information about changes that may be needed on an app, and for more specific web integration details, see the google_sign_in_web
package.
To use this plugin, follow the plugin installation instructions.
Add the following import to your Dart code:
import 'package:google_sign_in/google_sign_in.dart';
Initialize GoogleSignIn
with the scopes you want:
GoogleSignIn _googleSignIn = GoogleSignIn( scopes: [ 'email', 'https://www.googleapis.com/auth/contacts.readonly', ], );
Full list of available scopes.
You can now use the GoogleSignIn
class to authenticate in your Dart code, e.g.
Future<void> _handleSignIn() async { try { await _googleSignIn.signIn(); } catch (error) { print(error); } }
In the web, you should use the Google Sign In button (and not the signIn
method) to guarantee that your user authentication contains a valid idToken
.
For more details, take a look at the google_sign_in_web
package.
If your app supports both mobile and web, read this section!
Users may (or may not) grant all the scopes that an application requests at Sign In. In fact, in the web, no scopes are granted by signIn
, silentSignIn
or the renderButton
widget anymore.
Applications must be able to:
There's a new method that enables the checks above, canAccessScopes
:
final bool isAuthorized = await _googleSignIn.canAccessScopes(scopes);
(Only implemented in the web platform, from version 6.1.0 of this package)
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).
Future<void> _handleAuthorizeScopes() async { final bool isAuthorized = await _googleSignIn.requestScopes(scopes); if (isAuthorized) { // Do things that only authorized users can do! _handleGetContact(_currentUser!); } }
The requestScopes
returns a boolean
value that is true
if the user has granted all the requested scopes or false
otherwise.
Once your app determines that the current user isAuthorized
to access the services for which you need scopes
, it can proceed normally.
In the web, the accessToken
is no longer refreshed. It expires after 3600 seconds (one hour), so your app needs to be able to handle failed REST requests, and update its UI to prompt the user for a new Authorization round.
This can be done by combining the error responses from your REST requests with the canAccessScopes
and requestScopes
methods described above.
For more details, take a look at the google_sign_in_web
package.
canAccessScopes
?The new web SDK implicitly grant access to the email
, profile
and openid
scopes when users complete the sign-in process (either via the One Tap UX or the Google Sign In button).
If an app only needs an idToken
, or only requests permissions to any/all of the three scopes mentioned above (OpenID Connect scopes), it won't need to implement any additional scope handling.
If an app needs any scope other than email
, profile
and openid
, it must implement a more complete scope handling, as described above.
Find the example wiring in the Google sign-in example application.