Setting up OAuth 2.0

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:

1. Go to the Google API Console OAuth consent screen page.
2. Add required information like a product name and support email address.
3. Click Add Scope.
4. 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. 
5. When you're finished adding details to the OAuth consent screen, click Submit for verification.
6. A Verification required window displays.
7. 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.

• 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.

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.

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:

1. Open the Google Cloud Platform Console Credentials page.
2. If it's not already selected, select the project that you're creating credentials for.
3. To set up a new service account, click New credentials and then select Service account key.
4. Choose the service account to use for the key.
5. 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.

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.

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 iOS Universal Windows Platform (UWP) Chrome apps TVs & limited-input devices Desktop apps