Configuration

This page covers configuration options for the Google identity provider beyond the basic setup.

Configuration options

Below is a non-exhaustive list of some of the most common configuration options. For more details on all options, check the GoogleIdpConfig in-code documentation.

Loading Google Client Secret

You can load the Google client secret in several ways:

From JSON string (recommended for production):

final googleIdpConfig = GoogleIdpConfig(
  clientSecret: GoogleClientSecret.fromJsonString(
    pod.getPassword('googleClientSecret')!,
  ),
);

From JSON file:

final googleIdpConfig = GoogleIdpConfig(
  clientSecret: GoogleClientSecret.fromJsonFile(
    File('config/google_client_secret.json'),
  ),
);

From JSON map:

final googleIdpConfig = GoogleIdpConfig(
  clientSecret: GoogleClientSecret.fromJson({
    'web': {
      'client_id': 'your-client-id.apps.googleusercontent.com',
      'client_secret': 'your-client-secret',
      'redirect_uris': [
        'http://localhost:8080/auth/google/callback',
      ],
    },
  }),
);

Custom Account Validation

You can customize the validation for Google account details before allowing sign-in. By default, the validation checks that the received account details contains name, fullName, and verifiedEmail set to true.

final googleIdpConfig = GoogleIdpConfigFromPasswords(
  // Optional: Custom validation for Google account details
  googleAccountDetailsValidation: (accountDetails) {
    // Throw an exception if account doesn't meet custom requirements
    if (accountDetails.verifiedEmail != true ||
        !accountDetails.email!.endsWith('@example.com')) {
      throw GoogleUserInfoMissingDataException();
    }
  },
);

Accessing Google APIs

The default setup allows access to basic user information, such as email, profile image, and name. You may require additional access scopes, such as accessing a user's calendar, contacts, or files. To do this, you will need to:

• Add the required scopes to the OAuth consent screen.
• Request access to the scopes when signing in. Do this by setting the scopes parameter of the GoogleSignInWidget or GoogleAuthController.

A full list of available scopes can be found here.

info

Adding additional scopes may require approval by Google. On the OAuth consent screen, you can see which of your scopes are considered sensitive.

Accessing Google APIs on the Server

On the server side, you can access Google APIs using the access token. The getExtraGoogleInfoCallback in GoogleIdpConfig receives the access token and can be used to call Google APIs:

import 'package:http/http.dart' as http;

final googleIdpConfig = GoogleIdpConfigFromPasswords(
  // Optional: Extract additional info from Google APIs
  getExtraGoogleInfoCallback: (session, {
    required accountDetails,
    required accessToken,
    required transaction,
  }) async {
    // Use accessToken to call Google APIs and store additional info
    // Example: Access YouTube API
    final response = await http.get(
      Uri.https('www.googleapis.com', '/youtube/v3/channels?part=snippet&mine=true'),
      headers: {'Authorization': 'Bearer $accessToken'},
    );
    // Process response and store additional info in the database
  },
);

Lightweight Sign-In on the Flutter app

Lightweight sign-in is a feature that attempts to authenticate users previously logged in with Google automatically with minimal or no user interaction. When enabled, the Google authentication controller will try to sign in users seamlessly using platform-specific lightweight authentication methods. This feature is enabled by default, but can be disabled from the GoogleSignInWidget or GoogleAuthController.

GoogleSignInWidget(
  client: client,
  attemptLightweightSignIn: false, // Disable lightweight sign-in
  onAuthenticated: () {
    // User was automatically signed in
  },
)

info

If lightweight sign-in fails (e.g., no previous session exists or the user dismisses the prompt), the user can still use the regular sign-in button to authenticate manually.

note

The lightweight sign-in attempt happens automatically when the controller is initialized, typically at app launch. If successful, users will be signed in without any additional interaction.