Comply with OAuth 2.0 policies

When you're ready to deploy your implemented solution beyond your development environment to your app's users, you might need to take additional steps to comply with Google's OAuth 2.0 Policies. In this guide, we outline how to come into compliance with the most common developer issues encountered when you prepare your app for production. This helps you reach the largest possible audience with limited errors.

Use separate projects for testing and production

Google's OAuth policies require separate projects for testing and production. Some policies and requirements only apply to production apps. You might need to create and configure a separate project that includes OAuth clients that correspond to the production version of your app available to all Google Accounts.

Google OAuth clients used in production help provide a more stable, predictable, and secure data collection and storage environment than similar OAuth clients that test or debug the same application. Your production project can submit for verification and therefore be subject to additional requirements for specific API scopes, which might include third-party security assessments.

  2. Review the OAuth clients in this project that might be associated with your testing tier. If applicable, create similar OAuth clients for the production clients inside your production project.
  3. Enable any APIs in use by your clients.
  4. Review your OAuth Consent Screen configuration in the new project.

Google OAuth clients used in production must not contain test environments, redirect URIs, or JavaScript origins available to only you or your development team. The following are some examples:

  • The test servers of individual developers
  • Test or pre-release versions of your app

Maintain a list of relevant contacts for the project

Google, and the individual APIs you enable, might need to contact you about changes to its services or new configurations required of your project and its clients. Review your project's IAM listings to make sure relevant people on your team have access to edit or view your project configuration. These accounts might also receive emails about required changes to your project.

A role contains a set of permissions that lets you perform specific actions on project resources. Project editors have permissions for actions that modify state, such as the ability to make change to your project's OAuth consent screen. Project owners who have all editor permissions can add or remove accounts associated with the project, or delete the project. Project owners can also provide context for why billing information might be set. Project owners can set up billing information for a project that uses paid APIs.

Project owners and editors must be kept up-to-date. You can add multiple relevant accounts to your project to help ensure continued access to the project and related maintenance. We send emails to those accounts when there are notifications about your project or updates to our services. Google Cloud organization administrators must ensure that a reachable contact is associated with every project in their organization. If we don't have up-to-date contact information for your project, you might miss out on important messages that require your action.

Accurately represent your identity

Provide a valid app name and, optionally, a logo to show to users. This brand information must accurately represent the identity of your application. App branding information is configured from the OAuth .

For production apps, brand information defined in your OAuth consent screen must be verified before it displays to users. Users might be more likely to grant access to your app after it completes its brand verification. Basic application information, which includes the app's name, home page, terms of service, and privacy policy, are shown to users on the grant screen, when they review their existing grants, or to Google Workspace administrators that review app use by their organization.

Google can revoke or suspend access to Google API Services and other Google products and services for apps that misrepresent their identity or attempt to deceive users.

Only request scopes that you need

During your application's development, you might have used an example scope provided by the API to create a proof-of-concept within your application to learn more about the API's features and functionality. These example scopes often request more information than the final implementation of your app needs, because they provide comprehensive coverage of all possible actions for a particular API. For example, the example scope might request read, write, and delete permissions while your application requires only read permissions. Request relevant permissions that are limited to the critical information necessary to implement your application.

Review the reference documentation for the API endpoints that your app calls and note the scopes that they require to access the relevant data your app needs. Review any authorization guides that the API offers and describe their scopes in more detail to include the most common usage. Choose the most minimal data access that your application needs to power the related features.

For more information about this requirement, read the Only request scopes that you need section of the OAuth 2.0 Policies, along with the Request relevant permissions section of the Google API Services User Data Policy.

Submit production apps that use sensitive or restricted scopes for verification

Certain scopes are classified as "sensitive" or "restricted" and can't be used in production apps without review. Enter all scopes your production app uses in its OAuth Consent Screen configuration. If your production app uses sensitive or restricted scopes, you must submit your use of those scopes for verification before you include the scopes in an authorization request.

Only use domains you own

Google's OAuth consent screen verification process requires verification of all domains associated with your project's home page, privacy policy, terms of service, authorized redirect URIs, or authorized JavaScript origins. Review the list of domains in use by your app, summarized in the Authorized domains section of the OAuth consent screen editor, and identify any domains that you don't own and would therefore be unable to verify. To verify ownership of your project's authorized domains, use the Google Search Console. Use a Google Account that's associated with your project as an Owner or an Editor.

If your project uses a service provider with a common, shared domain, we recommend that you enable configurations that would allow use of your own domain. Some providers offer to map their services to a subdomain of a domain you already own.

Host a home page for production apps

Every production app that uses OAuth 2.0 must have a publicly accessible home page. Potential users of your app might visit the home page to learn more about the features and functionality that the app offers. Existing users might review their list of existing grants and visit your app's home page as a reminder of their continued use of your offering.

Your application's home page must include a description of the app's functionality, as well as links to a privacy policy and optional terms of service. The home page must exist on a verified domain under your ownership.

Use secure redirect URIs and JavaScript origins

OAuth 2.0 clients for web apps must secure their data using HTTPS redirect URIs and JavaScript origins, not plain HTTP. Google can reject OAuth requests that don't originate from or resolve to a secure context.

Consider which third-party applications and scripts might have access to tokens and other user credentials that return to your page. Limit access to sensitive data with redirect URI locations that are limited to verifying and storing token data.

Next steps

After you ensure that your app complies with the OAuth 2.0 policies on this page, see Submit for brand verification for details about the verification process.