Skip to main content

Configure an Application with Google OIDC

This guide explains how to configure an application with Google as an OpenID Connect (OIDC) Identity Provider (IdP).

The configuration is completed in the application using the following steps:

  1. Details
  2. Connection
  3. Provisioning & access
  4. Attribute mapping
  5. Review

Prerequisites​

Before configuring Google OIDC in the application, make sure you have:

  • Access to the application with permission to configure Identity Providers.
  • Access to a Google Cloud project.
  • A Google OAuth 2.0 Web application client.
  • The application's Redirect URI / Callback URL.
  • The application's required user attributes, such as email and name.

For Google configuration, see the official Google OAuth 2.0 documentation and Google OpenID Connect documentation.

Step 1: Create Google OAuth Credentials​

First, create an OAuth client in Google Cloud. The client credentials are used by the application to authenticate users through Google.

1.1 Open Google Cloud Console​

Open the Google Cloud Console and select the Google Cloud project that you want to use.

Go to:

Google Cloud Console → Google Auth Platform / APIs & Services → Clients / Credentials

Google may display the OAuth configuration under Google Auth Platform in the current console experience.

If the OAuth consent screen has not been configured, open the Google OAuth consent screen and provide the required application information.

Configure:

  • Application name – The name users will see when signing in.
  • User support email – An email address users can use for support.
  • Audience – Select the appropriate audience for your organization.
  • Authorized domains – Add the domain used by your application, when required.
  • Scopes – Request only the scopes required by your application.

For basic OIDC authentication, the commonly used scopes are:

openid
email
profile

See Google's OAuth consent screen documentation for more information.

1.3 Create an OAuth client​

Open the Google Cloud Credentials page.

Select:

Create credentials → OAuth client ID

Choose:

Application type → Web application

Enter a recognizable name for the client.

1.4 Add the application's Redirect URI​

In Authorized redirect URIs, add the callback URL provided by your application.

Example:

https://<your-application-domain>/<your-oidc-callback-path>

Use the exact Redirect URI displayed by your application. Do not add a trailing slash or change the protocol unless the application specifies it.

For local development, your application may provide a localhost callback URL.

Google requires the redirect URI used by the authorization request to match an authorized redirect URI.

See Google's Web Server OAuth 2.0 guide for redirect URI requirements.

1.5 Save the Client ID and Client Secret​

After creating the OAuth client, Google provides:

  • Client ID
  • Client Secret

Keep the Client Secret secure. Do not commit it to source control or expose it in client-side code.

Step 2: Configure the Identity Provider in the Application​

Open the application's Identity Providers section and start a new configuration.

Select:

Identity Provider → OIDC → Google

The configuration wizard opens with the following steps.

Step 2.1: Details​

The Details step contains the basic information about the Identity Provider.

Enter a name that makes the provider easy to identify.

Example:

FieldValue
NameGoogle
Provider typeOIDC
DescriptionGoogle OpenID Connect

If the application provides an Enabled option, enable the provider when you are ready to make it available to users.

Click Continue.

Step 2.2: Connection​

The Connection step contains the OIDC connection settings.

Use the following Google OIDC values.

Application fieldGoogle OIDC value
Issuerhttps://accounts.google.com
Authorization Endpointhttps://accounts.google.com/o/oauth2/v2/auth
Token Endpointhttps://oauth2.googleapis.com/token
UserInfo Endpointhttps://openidconnect.googleapis.com/v1/userinfo
Client IDThe Client ID created in Google Cloud
Client SecretThe Client Secret created in Google Cloud
Scopesopenid email profile

If the application supports OIDC Discovery URL, use Google's discovery document:

https://accounts.google.com/.well-known/openid-configuration

The discovery document allows the application to retrieve Google's supported OIDC endpoints and metadata automatically.

See the official Google OpenID Connect API Reference.

Client authentication​

If the application asks how the client authenticates with the token endpoint, use the method supported by your application and Google configuration. For a standard confidential web application, the client secret is typically used when exchanging the authorization code for tokens.

Scopes​

Enter:

openid email profile
  • openid enables OpenID Connect authentication.
  • email requests the user's email address.
  • profile requests basic profile information.

Click Continue.

Step 2.3: Provisioning & Access​

The Provisioning & access step controls which users can use the configured Google Identity Provider and how access is handled.

Configure the options according to your application's access model.

Typical configuration:

SettingRecommended configuration
Provider statusEnabled
User accessAllow users/groups that should sign in
Account creationEnable if the application supports JIT/user creation
Existing user matchingMatch by a stable identifier or verified email, according to application policy

Just-in-time user provisioning​

If the application supports Just-in-Time (JIT) provisioning, a user can be created automatically the first time they authenticate through Google.

If JIT provisioning is disabled, users may need to be created or assigned in the application before they can sign in.

The exact provisioning and access fields depend on the application. Use the access policy defined by your organization.

Click Continue.

Step 2.4: Attribute Mapping​

The Attribute mapping step maps claims received from Google to user attributes in the application.

A typical mapping is:

Application attributeGoogle OIDC claimPurpose
User ID / SubjectsubStable Google user identifier
EmailemailUser email address
First namegiven_nameUser first name
Last namefamily_nameUser last name
Display namenameUser display name
Profile picturepictureOptional profile image
sub          → User ID / External ID
email        → Email
given_name   → First Name
family_name  → Last Name
name         → Display Name
picture      → Profile Picture

Important: Use sub as the stable identifier​

The Google sub claim is the user's unique and stable identifier within Google's OIDC identity system.

Do not use the user's display name as the unique identifier.

Google's OIDC UserInfo documentation describes the sub, email, name, given_name, family_name, and picture claims.

Click Continue.

Step 2.5: Review​

The Review step displays all configuration values before the Identity Provider is saved.

Review the following:

Details​

  • Provider name is correct.
  • Provider type is OIDC.

Connection​

  • Issuer is correct.
  • Discovery URL is correct, if used.
  • Client ID matches the Google OAuth client.
  • Client Secret is correct.
  • Required scopes are configured.
  • Redirect URI configured in Google exactly matches the application's callback URL.

Provisioning & access​

  • The provider is enabled if required.
  • The correct users or groups have access.
  • JIT provisioning is configured according to your organization's requirements.

Attribute mapping​

Verify that:

sub          → User ID / External ID
email        → Email
given_name   → First Name
family_name  → Last Name
name         → Display Name

Click Save, Create, or Finish, depending on the application's UI.

Step 3: Test Google OIDC Login​

After saving the configuration, test the authentication flow.

  1. Open the application's login page.
  2. Select Sign in with Google or the configured Google Identity Provider.
  3. Google displays the authentication and consent screen.
  4. Sign in with an allowed Google account.
  5. Google redirects the user back to the application's Redirect URI.
  6. The application validates the OIDC response and creates or signs in the user.
  7. Verify that the user's attributes were populated correctly.

Expected result​

After successful authentication:

  • The user is redirected back to the application.
  • The user is authenticated.
  • The expected email and profile information are available.
  • The user receives the access configured in the Provisioning & access step.

Troubleshooting​

redirect_uri_mismatch

This error usually means the Redirect URI in the application does not exactly match the URI configured in Google Cloud.

Check:

  • Protocol (http vs https)
  • Domain
  • Port
  • Path
  • Trailing slash
  • Environment-specific callback URL

Update the Authorized redirect URI in the Google OAuth client to exactly match the application's value.

See Google's OAuth redirect URI documentation.

invalid_client

Check that:

  • The Client ID is correct.
  • The Client Secret is correct.
  • The credentials belong to the selected Google Cloud project.
  • The OAuth client has not been deleted or disabled.

User is authenticated but not created​

Check the Provisioning & access settings.

If the application uses JIT provisioning, verify that JIT is enabled. If users must be assigned manually, make sure the Google user or group has been granted access.

Email or name is missing​

Check the Attribute mapping configuration.

Make sure the application maps:

email       → Email
given_name  → First Name
family_name → Last Name
name        → Display Name

Also verify that the required email and profile scopes are configured.

Official References​