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
- Maintain a list of relevant contacts for the project
- Accurately represent your identity
- Only request scopes that you need
- Submit production apps that use sensitive or restricted scopes for verification
- Only use domains you own
- Host a home page for production apps
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.
- Go to the Google API Console. Click Create project, enter a name, and click Create.
- 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.
- Enable any APIs in use by your clients.
- Review your OAuth Consent Screen configuration in the new project.
- 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 Consent Screen page.
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
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.
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.
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.