OAuth Application Verification FAQ

This page has answers to frequently asked questions about Google Cloud Platform OAuth policy violations.

Expand all Collapse all  

Sensitive Scope App Verification

What are sensitive API scopes?

Sensitive scopes allow access to Google User Data. If an app uses sensitive scopes, it must comply with the Google API User Data Policy asnd have its OAuth consent screen configuration verified by Google.

Under what circumstances does my app have to be verified by Google?

Your app may also need to undergo verification if:

  • Your app displays an icon on the OAuth consent screen
  • The number of authorized domains for your apps exceed the domain count limit for a project
  • Your app uses any of the sensitive scopes to request Google User Data
How can I ensure the verification process is quick and smooth?

To ensure the process is quick and smooth:

  • Verify domain ownership of all your authorized domains with Google through Search Console by using an account that is either a Project Owner or a Project Editor on your OAuth Project.
    Note: If you are using a third party service provider and your domain is owned by them, then you need to provide a detailed justification for us to validate it.
  • Ensure that your app's Privacy Policy meets the following requirements:
    • The Privacy Policy must be visible to users, hosted within the domain of your website, and linked to the OAuth consent screen on the Google API Console.
    • The Privacy Policy must disclose the manner in which your application accesses, uses, stores, or shares Google user data. Your use of Google user data must be limited to the practices explicitly disclosed in your published Privacy Policy.
  • Ensure that each scope that you're requesting has an explanation for its use/need for the project, as well as a justification for why a narrower scope would be insufficient.
  • Ensure all OAuth branding information on the OAuth consent screen, such as the project name shown to users, support email, homepage URL, privacy policy URL, and so on, accurately represents the app's identity.
  • If you use Google Sign-In Scopes in your app, please ensure that your app is compliant per these branding guidelines:
  • For information about using the new consent screenflow, see Setting up OAuth 2.0.
  • If you are requesting a restricted Scope, please reference the Restricted Scope App Verification section.
Why can't I see the API scopes in the scope picker?

To view the API scopes:

  • Go to the Google API Console Library page.
  • Ensure the relevant project is selected.
  • Search for and enable the API for which you need the scopes to be verified.
  • Enabled API scopes are visible in scope picker on OAuth Credentials page

For a detailed list of APIs and relevant OAuth scopes, see OAuth 2.0 Scopes for Google APIs.

Note: For Apps Scripts projects, please refer to the OAuth Client Verification guide for more instructions.

I need help selecting scopes for my app. Where can I find support for various product APIs?

If you need help deciding which scopes to use for your app, please refer to the OAuth 2.0 Scopes for Google APIs support page.

When can I skip publishing my app for a review?

You do not need to request for verification if your app is going to be used in any of the following scenarios:

  • The app is not shared with anyone else.
  • The app is used to send emails through Wordpress, or similar single account SMTP plug-ins.
  • The owner and users of your apps belong to the same G Suite domain or customer.
  • The app is trying to access data from users' Google Cloud Platform project. For instructions on using a service account, see Using OAuth 2.0 for Server to Server Applications.
What happens if I don't publish my app for review?

If you don't publish your app for review:

  • If your public application uses sensitive scopes that permit access to certain user data, users of your application might see an Unverified App screen.
  • To protect users and Google systems from abuse, applications that use OAuth and Google Identity have certain quota restrictions based on the risk level of the OAuth scopes an app uses. Failure to get your app verified might result in your project quota getting exhausted. Learn more about Unverified Apps.
How can I access data from my users' Google Cloud Platform project using Cloud APIs?

You can access data from your users' Google Cloud Platform projects by creating a service account to represent your service, and then having your customers grant that service account appropriate access to their cloud data using IAM policies. Note that you might want to create a service account per customer if you need to avoid confused deputy problems. To familiarize yourself and educate your users on using service accounts and updating cloud IAM policies, see the following articles.

Service Account Creation:

IAM Policies:

If your users are having issues creating a service account or using IAM policies to grant your project the appropriate permissions, please direct them to Google Cloud Support.

Restricted Scope App Verification

What are restricted API scopes?

Like sensitive scopes, restricted scopes allow access to Google User Data. If an app uses restricted scopes, it must comply with the Google API User Data Policy and have its OAuth consent screen configuration verified by Google. In addition, Google verifies that an app that uses restricted scopes complies with the Additional Requirements for Specific API Scopes.

  • https://mail.google.com/
  • https://www.googleapis.com/auth/gmail.readonly
  • https://www.googleapis.com/auth/gmail.metadata
  • https://www.googleapis.com/auth/gmail.modify
  • https://www.googleapis.com/auth/gmail.insert
  • https://www.googleapis.com/auth/gmail.compose
  • https://www.googleapis.com/auth/gmail.settings.basic
  • https://www.googleapis.com/auth/gmail.settings.sharing
Which apps need to submit for verification?

All apps that request a restricted API scope need to submit for verification. This includes web, iOS, Android, and other native client types.

How can I prepare to submit for verification on Jan 15th, 2019?
  • Verification can be submitted from the Google API Console starting Jan 15th, 2019.
  • The information needed include declaring your application type, an explanation for why each scope that you're requesting is needed for the project, and an agreement stating that your usage of restricted scopes comply with all Additional Requirements for Specific API Scopes.
  • The item that will likely take the most time is to prepare updates to your privacy policy in order to comply with the Limited Use policy.
How does this apply to my enterprise accounts (G Suite, Cloud Identity)?

These changes only impact consumer Google accounts (@gmail.com), not G Suite or Cloud Identity accounts. Note that G Suite administrators are able to control which applications their users can access.

If my app is only for my enterprise, do I need to submit for verification?

It depends. If you develop internal apps for users in your G Suite domain, you do not need to submit for verification. If you develop apps for users in a different G Suite domain (or consumer accounts), you will need to submit for verification.

What is the restricted scope app verification and how is it different from the sensitive scope app verification?
What are the key dates for application verification?

For apps passing verification under the sensitive scope app verification prior to January 15, 2019

If your existing applications access restricted scopes, you must re-apply for verification via the new verification process. You can apply between January 15, 2019 and February 15, 2019. If your existing applications have not been submitted for verification by February 15, they may have consumer account access disabled for new users on February 22, 2019 and existing grants revoked by March 31, 2019. Starting March 31, 2019, only users with project owner, editor and viewer permissions (that is, the app developers) will get access to the app if you do not submit your app for verification.

For new and unverified apps applying for restricted scope verification on or after January 15th, 2019

Starting January 15, 2019, new apps using restricted scopes must apply for verification before getting full access to the restricted scopes. You should expect the process to take several weeks.

How long will the verification process take?

App verifications are expected to take several weeks to account for clarification questions and re-submissions. Google will not take action against apps for non-compliance with the new policy during the verification process if they are promptly responding to clarifications and acting in good faith to come into compliance. User access to the app for existing approved scopes will not be impacted. All apps that have applied are expected to fully complete the app verification process by May 15, 2019 with the remainder of 2019 to complete the security assessment.

What if I have several apps requesting restricted scopes; will they all need to be verified?

Yes, all Google Cloud projects that access restricted scopes must be submitted for verification.

If my app uses a combination of restricted and non-restricted APIs, will I need to submit for verification?

Yes, your app will need to be submitted for verification. If it is not, access to all restricted and non-restricted API scopes will be disabled for consumer accounts.

If Google announces additional APIs that fall into the restricted scope category and thus need to complete an application verification, do I need to re-submit for another verification?

As new policies for APIs are announced, your app will need to be re-verified. Any changes made to your app to comply with the policy should enable the verification to be completed more efficiently, though your app may need to address API-specific policies.

How do I get my verification completed faster?

Your verification can be completed faster if your submission is as detailed and thorough as possible. Please make sure the following are prepared:

  • Your app can be accessed and used by our verification team with their test accounts.
  • Your app’s website is complete, descriptive and includes easy access to the privacy policy.
  • If your app uses restricted scopes, ensure your app’s privacy policy complies with the Limited Use section of the API policies.
Why is the security assessment needed?

To help keep user data safe, we are requiring apps that store data on non-Google servers to demonstrate a minimum level of capability in handling data securely and deleting user data upon user request.

How will the security assessment work?

First, your application will be reviewed for compliance with the Google API Services: User Data Policy. Thereafter, you will have the remainder of 2019 to demonstrate compliance with the secure handling requirements. Assessments will be conducted by a third party, may cost between $15,000 and $75,000 (or more) depending on the complexity of the application, and will be payable by the developer. This fee may be required whether or not your app passes the assessment. We expect that fees will include a remediation assessment if needed. If your app has previously completed an adequate security assessment as determined by the assessor, you will be able to provide a letter of assessment that may reduce the scope of the review. More details will be available in January 2019.

Why is Google charging a fee for the security assessment?

The assessment fee is paid directly to the assessor and not to Google. The security assessment will be completed by a certified 3rd party to ensure the confidentiality of your application.

How often will users need to re-grant permission for reporting or monitoring services app types?

After an app has been verified and designated as a reporting or monitoring app types, users need to re-grant access on a regular basis, such as every 90 days. Refresh tokens for this app type will have a defined time period. While the app is in verification, it will be exempt from token expirations until the verification is complete.

What are the guidelines for managing re-grants with users when tokens have expired?

To ensure the best user experience, all apps should follow the token expiration requirements that are already in place. Apps are encouraged to check for token expiration on token exchange and prompt users to re-grant with user notification delivered via email, web interstitial or mobile app notification. For example, many apps already send users an email to re-connect access when their token is expired after a user changes their password.

Users are most likely to respond when the benefit of this app is clear from the notification. For example, if your app provides delayed flight notifications, your re-consent notification can remind the user that they should re-connect account access if they’d like to continue receiving notifications for their flights.

To prompt users for re-grant to the user’s account, your app can use the same OAuth authentication request that was used when the user first signed up for your app with the addition of the URL parameter prompt=consent as described in the Google OAuth documentation. Google OAuth will generate a new refresh token and send it back to your app. This new token now needs to be used going forward.

Could I get more examples of how data may not be used?

To provide clarity to developers, the following uses of data obtained from restricted scopes are not considered to be providing user-facing features.

  • Aggregating data for market research purposes benefitting the developer or third parties
  • Monitoring email campaign tracking for campaign senders
  • Advertising for third parties

This list is not exhaustive. This article may be updated with additional examples in the future to clarify the allowable uses of data.

What if my app is not one of the Application Types?

If you are unsure of your app’s Application Type, you can select None of these when submitting the app for verification and our verification team will make this determination.

How can I ask questions about these policies and changes?

Developers can submit questions to oauth-help@google.com. The verification team will review the questions and provide a response by updating this FAQ. In some cases, an email response may be provided on a best-effort basis.

Was this article helpful?
How can we improve it?