Setting up OAuth 2.0

To use OAuth 2.0 in your application, you need an OAuth 2.0 client ID, which your application uses when requesting an OAuth 2.0 access token.

To create an OAuth 2.0 client ID in the console:

Go to the API Console.
From the projects list, select a project or create a new one.
If the APIs & services page isn't already open, open the console left side menu and select APIs & services.
On the left, click Credentials.
Click New Credentials, then select OAuth client ID.
Note: If you're unsure whether OAuth 2.0 is appropriate for your project, select Help me choose and follow the instructions to pick the right credentials.
Select the appropriate application type for your project and enter any additional information required. Application types are described in more detail in the following sections.
If this is your first time creating a client ID, you can also configure your consent screen by clicking Consent Screen. (The following procedure explains how to set up the Consent screen.) You won't be prompted to configure the consent screen after you do it the first time.
Click Create client ID

To delete a client ID, go to the Credentials page, check the box next to the ID, and then click Delete.

User consent

When you use OAuth 2.0 for authentication, your users are authenticated after they agree to terms that are presented to them on a user consent screen. Google verifies public applications that use OAuth 2.0 and meet one or more of the verification criteria.

Learn more about public versus internal applications below. For more information about the verification process, see the OAuth Application Verification FAQ.

If your application uses sensitive scopes without verification, the unverified app screen displays before the consent screen for users who are outside of your G Suite organization. To remove the unverified app screen, you can request OAuth developer verification by our team when you complete the Google API Console OAuth consent screen page.

To set up your project's consent screen and request verification:

Go to the Google API Console OAuth consent screen page.
Add required information like a product name and support email address.
Click Add Scope.
On the dialog that appears, select the scopes your project uses. Sensitive scopes display a lock icon next to the API name.
- To select scopes for registration, you need to enable the API, like Drive or Gmail, from APIs & Services > API Library.
- You must select all scopes used by the project.
When you're finished adding details to the OAuth consent screen, click Submit for verification.
A Verification required window displays.
Add scopes justification, a contact email address, and any other information that can help the team with verification, then click Submit.

Note: The consent screen settings within the console are set at the project level, so the information that you specify on the Consent screen page applies across the entire project.

When a project goes through verification, the current status displays under Verification status:

Not Published: your OAuth consent screen is not published and verification is not required for use.
Needs Verification: an OAuth developer verification is needed. To start the verification process, click Submit for Verification. For information about when verification is required, see the FAQ "When does my app have to be verified by Google?".
Being verified: an OAuth developer verification is in progress.
Published: your OAuth consent screen passed the verification and your project is verified.
Failed verification: your OAuth consent screen didn't pass the verification. Your last approved consent screen is still in use. You'll receive more information at the contact email you provided.

For more information about user authentication, see the OAuth 2.0 documentation.

Public and internal applications

A public application allows access to users outside of your organization (@your-organization.com).
- Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com.
- Public applications need to go through verification as detailed above.
An internal application will only allow access to users from your organization (@your-organization.com).

For more information about setting up organizations and organization access, see the GCP Organizations documentation.

Authorized domains

To protect you and your users, Google restricts your OAuth 2.0 application to using Authorized Domains. If you have verified the domain with Google, you can use any Top Private Domain as an Authorized Domain.

After you add an Authorized Domain, you can use any of its subdomains or pages, and any other associated country codes.

Add your Authorized Domains before you add your redirect or origin URIs, your homepage URL, your terms of service URL, or your privacy policy URL.

Service accounts, web applications, and native applications

For information about setting up service accounts, web applications, or device-native applications, see the following topics.

Service accounts

A service account is used in an application that calls APIs on behalf of an application that does not access user information. This type of application needs to prove its own identity, but it does not need a user to authorize requests.

For example, if your project employs server-to-server interactions such as those between a web application and Google Cloud Storage, then you need a private key and other service account credentials. To generate these credentials, or to view the email address and public keys that you've already generated, do the following:

Open the API Console Credentials page.
If it's not already selected, select the project that you're creating credentials for.
To set up a new service account, click New credentials and then select Service account key.
Choose the service account to use for the key.
Choose whether to download the service account's public/private key as a standard P12 file, or as a JSON file that can be loaded by a Google API client library.
Your new public/private key pair is generated and downloaded to your machine; it serves as the only copy of this key. You are responsible for storing it securely.

Your project needs the private key when requesting an OAuth 2.0 access token in server-to-server interactions. Google does not keep a copy of this private key, and this screen is the only place to obtain this particular private key. When you click Download private key, the PKCS #12-formatted private key is downloaded to your local machine. As the screen indicates, you must securely store this key yourself.

The name of the downloaded private key is the key's thumbprint. When inspecting the key on your computer, or using the key in your application, you need to provide the password notasecret. Note that while the password for all Google-issued private keys is the same (notasecret), each key is cryptographically unique.

You can generate multiple public-private key pairs for a single service account. This makes it easier to update credentials or roll them over without application downtime. However, you cannot delete a key pair if it is the only one created for that service account.

Use the email address when granting the service account access to supported Google APIs.

For more details, see the OAuth 2.0 Service Accounts documentation.

Note: When you use a service account, you are subject to the Terms of Service for each product, both as an end user and as a developer.

Web applications

A web application is accessed by web browsers over a network.

Applications that use client-side JavaScript to access Google APIs must specify authorized JavaScript origins. The origins identify the domains from which your application can send API requests.

Applications that access Google APIs from a server (often using languages and frameworks like Node.js, Java, .NET, and Python) must specify authorized redirect URIs. The redirect URIs are the endpoints of your application server to which the OAuth 2.0 server can send responses.

Native applications

If your application is going to be installed on a device or computer (such as a system running Android, iOS, Universal Windows Platform, Chrome, or any desktop OS), you can use Google's OAuth 2.0 Mobile and desktop apps flow. If your application runs on devices with limited input capabilities, such as smart TVs, you can use Google’s OAuth 2.0 TV and limited-input device flow.

Android

Note: Currently, obtaining OAuth 2.0 access tokens via AccountManager works for Android Ice Cream Sandwich (4.0) and newer versions.

You need to specify your Android app's package name and SHA1 fingerprint.

In the Package name field, enter your Android app's package name.

In a terminal, run the keytool utility to get the SHA1 fingerprint for your digitally signed .apk file's public certificate.

keytool -exportcert -alias androiddebugkey -keystore path-to-debug-or-production-keystore -list -v

Note: For the debug.keystore, the password is android. For Android Studio, the debug keystore is typically located at ~/.android/debug.keystore.

The Keytool prints the fingerprint to the shell. For example:

$ keytool -list -v -keystore ~/.android/debug.keystore
Enter keystore password: Type "android" if using debug.keystore
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: androiddebugkey
Creation date: Mar 13, 2020
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: C=US, O=Android, CN=Android Debug
Issuer: C=US, O=Android, CN=Android Debug
Serial number: 1
Valid from: Fri Mar 13 09:59:25 PDT 2020 until: Sun Mar 06 08:59:25 PST 2050
Certificate fingerprints:
	 SHA1: D9:E9:59:FA:7A:46:72:4E:69:1F:96:18:8C:F9:AE:82:3A:5D:2F:03
	 SHA256: 92:59:1E:F4:C9:BC:72:43:1C:59:57:24:AD:78:CA:A2:DB:C7:C5:AC:B1:A3:E8:52:04:B2:00:37:53:04:0B:8E
Signature algorithm name: SHA1withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 1

Copy the SHA1 fingerprint from the results that appear in your terminal.

Important: When you prepare to release your app to your users, follow these steps again in a production project and create a new OAuth 2.0 client ID for your production app. For production apps, use your own private key to sign the production app's .apk file. For more information, see Signing your applications.
Paste the SHA1 fingerprint into the form where requested.
(Optional) Verify ownership of your Android application.
You can verify ownership of your Android application to reduce the risk of app impersonation. Learn more about verifying ownership of your Android application.
Click Create.

Advanced settings

Custom URI scheme

This setting enables custom URI schemes for your Android client. Custom URI schemes aren’t recommended and are disabled by default on Android because they are vulnerable to app impersonation. Learn more about custom URI schemes and recommended alternatives.

iOS

If your application accesses APIs directly from iOS, you will need the application's Bundle ID and, optionally, its Apple App Store ID and Team ID:

The application's Bundle ID is the bundle identifier as listed in the app's .plist file. For example: com.example.myapp.
The application's App Store ID is in the app's App Store URL, if the app was published in the Apple App Store. For example, in the app URL https://apps.apple.com/us/app/google/id284815942, the App Store ID is 284815942.
The application's Team ID is a 10-character string that Apple assigns to your team. For information about your Team ID, see Locating your Team ID in the Apple App Distribution Guide.

After creating your iOS credentials and obtaining a Client ID, you use the Installed Application OAuth 2.0 flow to communicate with Google APIs.

Universal Windows Platform (UWP)

If your application runs on Universal Windows Platform, you will need your app’s 12-character Store ID. You can find this value in the Partner Center, on the App identity page of the App management section. This value can also be found as the last part of your app's Microsoft Store URL. For example: https://www.microsoft.com/store/apps/YOUR_STORE_ID

Chrome apps

Google Chrome apps and extensions are a special case of installed applications. Chrome exposes JavaScript APIs to allow your Chrome apps and extensions to perform various operations. Some of these APIs rely on knowing the identity of the user who is signed in to Chrome. If you're writing a Chrome app or extension that calls APIs that need to know the user's identity, and you want your app or extension to get user authorization for these requests using OAuth 2.0, then choose Chrome as the platform when you create your credentials. You will need to enter your Chrome app or extension's Application ID. For more information about these APIs, see the User Authentication documentation.

Verify app ownership

You can verify ownership of your Chrome application to reduce the risk of app impersonation. Learn more about verifying ownership of your Chrome application.

TVs & limited-input devices

The console does not require any additional information to create OAuth 2.0 credentials for applications running on limited-input devices, such as TVs.

Desktop apps

The console does not require any additional information to create OAuth 2.0 credentials for desktop applications.

Rotating your client secrets

Client secrets or credentials should be treated with extreme care as described in the OAuth 2.0 policies, because they allow anyone who has them to use your app's identity to gain access to user information. With the client secret rotation feature, you can add a new secret to your OAuth client configuration, migrate to the new secret while the old secret is still usable, and disable the old secret afterwards. This is useful when the client secret has been inadvertently disclosed or leaked. This also ensures good security practices by occasionally rotating your secrets without causing downtime of your app. In addition, Google started to issue more secure client secrets recommended by RFC 6749 in 2021. While apps that were created earlier are able to continue using the old secrets, we recommend that you migrate to the new secret with this rotation feature.

To rotate your client secret, please follow the following steps:

Step 1: Create a new client secret

Go to the API Console Credentials page.
If it's not already selected, select the project that you want to update.
From the list of OAuth 2.0 Client IDs, click the client you want to generate a new client secret for.
On the client details page, click Add Secret on the right side to add a new secret.
A new secret will appear below the old secret. You can also differentiate them by the secret creation time. The new secret will be in "Enabled" state and ready to be used.

Note 1: Both secrets can be used until you manually disable them. You must update your app to use the new secret and disable the old one as soon as possible after creating it to minimize security risks.

Note 2: You can only have two client secrets at maximum. If the client already has two secrets, to create a new secret, you must first disable and delete an existing secret.

Step 2: Configure your app to use the new secret

Next, update your app to use the new secret. Remember to handle your client secrets securely as described in the OAuth 2.0 policies.

You need to monitor your app and make sure the new secret has fully taken effect. In other words, make sure the old secret is not used anywhere in your app. Check the metrics and configurations used by your app to confirm that only the new client secret is used, for example:

References in code or configurations.
Your app or server logs.
The rollout status of your updated app version or configuration.
Any other metrics you may have.

Step 3: Disable the old secret

Having more than one enabled secrets for a client increases security risks. Once you confirm that your app has fully migrated to the new secret per the instructions in Step 2, you must disable the old secret.

Go to the API Console Credentials page.
From the list of OAuth 2.0 Client IDs, click the client you want to update.
Find the old secret you want to disable. Generally it should be the one with the earlier creation time.
Click Disable on the right side. The old secret will be invalid shortly.

Note: A disabled client secret will be rejected in OAuth flows. You are expected to continuously monitor your app and see if it’s working properly. In case you notice the app is failing because it is still using the old secret, you may click Enable to reinstate the secret on your client details page in API Console Credentials page. In this case, you should redo this step after completing the migration.

Step 4: Delete the old secret

Once you've confirmed that your app is working seamlessly with the new client secret, you are safe to delete the disabled old secret. To delete the secret, click the delete button next to it. Note that this cannot be undone.