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 and have its OAuth consent screen configuration verified by Google.

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

Your app may need to undergo verification if:

  • Your app uses any of the sensitive scopes to request Google User Data
  • You want your application to display an icon or display name instead of the redirect URL domain on the OAuth consent screen
  • The number of authorized domains for your apps exceed the domain count limit for a project
  • There are changes to the OAuth consent screen after your app has been approved
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 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.
  • Please include a YouTube link to a demo video demonstrating the OAuth grant process by users and explaining, in detail, the usage of sensitive and restricted scopes within the app’s functionality for each OAuth client belonging to the project.
    • Note that the video should clearly show the app's details such as the app name, OAuth client ID, and so on. For multiple client IDs, the demo video should show usage of sensitive and restricted scopes on each client.
    • Including the video along with the verification request will speed up the approval process significantly.
    • Note that approval will not be granted if scope usage on each OAuth client ID is not adequately explained. Additionally, if any of your OAuth clients in the project requesting verification are not ready for testing, we will be unable to complete our review and your request will be rejected. We strongly recommend you separate your test and production projects and move OAuth clients still in development into a test project before requesting verification. Your apps will be thoroughly reviewed by our teams.
  • 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 documentation.

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

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. This also means all OAuth Clients within a project requesting restricted scopes must be ready for verification once submitted. We suggest you delete or remove OAuth Clients that are not ready for production before submitting a verification request.

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, 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 Google-designated third party assessor, 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.

What will the security assessment include?

The security assessment includes the following.

  1. External Network Penetration Testing: Identify potential vulnerabilities in external, internet-facing infrastructure, systems such as the following:
    • Discovery and enumeration of live hosts, open ports, services, unpatched software, administration interfaces, authentication endpoints lacking MFA, and other external-facing assets
    • Automated vulnerability scanning combined with manual validation
    • Brute-forcing of authentication endpoints, directory listings, and other external assets
    • Analysis of potential vulnerabilities to validate and develop complex attack chaining patterns and custom exploits
    • Potential exploitation of software vulnerabilities, insecure configurations, and design flaws
  2. Application Penetration Testing: Identify potential vulnerabilities in application that access Google user data such as the following:
    • Real-world attack simulation focused on identification and exploitation
    • Discovery of attack surface, authorization bypass, and input validation issues
    • Automated vulnerability scanning combined with manual validation
    • Exploitation of software vulnerabilities, insecure configurations, design flaws, and weak authentication
    • Analysis of vulnerabilities to validate and develop complex attack chaining patterns and custom exploits
    • Verify the ability for users to delete their account with no external indication that the user or user’s content is accessible.
  3. Deployment Review: Identify exploits and vulnerabilities in developer infrastructure such as the following:
    • Gathering all available configuration settings and metadata as well as manual techniques to build a profile of the cloud environment
    • Analyzing collected information to identify any gaps or deviations from accepted cloud security best practices
    • Manually examining configuration settings to locate anomalies and issues such as weak IAM policies, exposed storage containers, poorly defined security groups, insecure cloud services usage, and insecure key management
    • Exploitation of vulnerabilities, insecure configurations, design flaws, and weak authentication – as needed
    • Verify storage of OAuth tokens is encrypted and encryption keys and secrets are stored in a hardware security module or equivalent strength key manager
    • Ensure developer access to the deployment environment is secured with multi-factor authentication
  4. Policy and Procedure Review: Review and examine the efficacy of information security policies and procedures such as the following:
    • Incident Response Plan: Establishes roles, responsibilities and actions when an incident occurs
    • Risk Management Policy: Identify, reduce and prevent undesirable incidents or outcomes
    • Vulnerability Disclosure Program: Provide means for external parties to report vulnerabilities
    • Information Security Policy: Ensures all users comply with rules and guidelines related to the security of the information stored digitally at any point in the network

The list of activities may be updated quarterly. Each app will be required to re-assess annually. At that time, updated activities may be included in the assessment.

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.

For the secure handling policy, what are “local client applications” and when will they be exempt from security assessments?

Local client applications are generally applications that only run, store, and process data on the user’s device (like a computer, mobile phone, or tablet). While user actions may cause data to leave a device (such as sending an email), local client applications do not transmit restricted scope data to the developer’s servers (or servers specified by the developer), unless the user explicitly configured the application to do so. This would include local email clients, file managers, and calendar and contact management applications that don’t utilize cloud services or only transmit restricted scope data to user-configured destinations. Applications that send restricted scope data to a developer’s or third party’s servers without explicit user-initiated action will not be considered a local client.

These applications may be exempt from the secure handling policy because the security assessment (and successful securement of a Letter of Assessment) primarily addresses risks associated with developers obtaining and storing data on servers.

Developers should specify in the verification application whether they believe the application is a local client application, and we will work with the developer to verify that is the case.

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.

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.

Could you explain the Limited Use requirements for me?

The Limited Use requirements have four elements:

  1. Allowed Use: Developers are only allowed to use restricted scope data to provide or improve user-facing features that are prominent from the requesting app’s user interface. It should be clear to your users why and how you use the restricted scope data they’ve chosen to share with you.
  2. Allowed Transfer: Developers are only allowed to transfer restricted scope data to others if that transfer is (a) necessary to provide or improve user-facing features that are prominent from the requesting app’s user interface, (b) to comply with applicable laws, or (c) a part of a merger, acquisition or sale of assets of the developer. All other transfers or sales of user data are completely prohibited.
  3. Prohibited Advertising: Developers are never allowed to use or transfer restricted scope data to serve users advertisements. This includes personalized, retargeted and interest-based advertising.
  4. Prohibited Human Interaction: Developers cannot allow humans to read restricted scope user data. For example, a developer with access to a user’s data is not allowed to have one of its employees read through a user’s emails. There are four limited exceptions to this rule: (a) the developer obtains a user’s consent to read specific messages (for example, for tech support), (b) it’s necessary for security purposes (for example, investigating abuse), (c) to comply with applicable laws, and (d) the developer aggregates and anonymizes the data and only uses it for internal operations (for example, reporting aggregate statistics in an internal dashboard).
How do I know if my privacy policy is inconsistent with the Limited Use requirements?

If your privacy policy describes practices around your app’s use of restricted scope data that would violate the Limited Use requirements, it is inconsistent with these requirements. Below are some examples of practices that would be inconsistent with the Limited Use requirements for restricted scopes.

Example 1: Market Research Not Permitted

We share your information with the following:

  • Affiliates who enhance our market research capabilities by combining the information we collect with other information available to them from other sources;
    [Reason: Impermissible transfer of data, if using data from a restricted API scope.]
  • Third-party business partners that work with us to develop and resell products;
    [Reason: Impermissible transfer of data, if using data from a restricted API scope.]
  • Customers that have access to our market research datasets and analyses.
    [Reason: Impermissible use and transfer of data, if using data from a restricted API scope.]

Example 2: Transfer of Anonymized Data Sets Not Permitted

The app uses your information as described in this policy, which includes creating anonymized data sets to improve our products and services and the products and services of our affiliates.
[Reason: Impermissible use and transfer of data to improve services outside the app using a restricted scope.]

We do not share, sell, or transfer your personal data for purposes other than those outlined in this policy. We may, however, disclose aggregated information about our users, and information that does not identify any individual, without restriction.
[Reason: Impermissible transfer and potential human reading of data. As a reminder, even aggregated and anonymized data are subject to Limited Use requirements.]

Example 3: Transfer with User Consent Not Permitted

We might share your information in any other way we might describe when you provide the information and for any other purpose with your consent.
[Reason: Impermissible use and transfer. Note that the Limited Use restrictions apply even if you seek permission from your users.]

Example 4: Advertising with User Data from Restricted Scopes Not Permitted

We transfer information to advertising partners who work with our App under confidentiality agreements.
[Reason: Impermissible transfer and use; confidentiality agreements do not make the transfer or use for advertising permissible under the Limited Use requirements.]

We may use your information to deliver advertisements according to our advertisers' target-audience preferences with your express consent.
[Reason: Impermissible use of data for advertising. Note that the Limited Use restrictions apply even if you seek permission from your users.]

We may also use your information to personalize your content, marketing, and recommendations, including to target content and services to more closely match your interests and location.
[Reason: Impermissible use of data for advertising. Your app may continue to deliver advertisements but may not use the user data from restricted scopes to affect advertising. Personalization of content and recommendations that follow the limited use requirements are permitted.]

What if my privacy policy covers multiple types of data, including non-restricted scope data?

Only data obtained from restricted scopes is subject to our Additional Requirements for Specific API Scopes.

We can’t tell you what your privacy policy should say because it will largely depend on your specific data practices, including how you may use, store, or transfer other data you collect. We recommend seeking legal advice on what’s right for your app.

With that in mind, if you use broad terms in your privacy policy to refer to data from restricted scopes and other types of data, we will interpret your disclosures as applying to user data from restricted scopes. You may consider, where possible, referring to data obtained from restricted scopes separately in your privacy policy. For example, if your app uses data from restricted scopes, such as Gmail data, as well as other data obtained from your users in your app, you might separate your disclosures regarding how you use those different sources of data.

What if my privacy policy says that my app complies with the Limited Use requirements?

You may decide to incorporate language from the Limited Use requirements, or other policies, directly into your privacy policy. However, keep in mind that the Google API Services: User Data Policy may change from time to time and that you are responsible for ensuring that your privacy policy remains consistent with these policies and other applicable laws/regulations around changes to your privacy policy and data practices.

Below is an example of language that may be appropriate if your app uses data from restricted scopes and is a web email client app. Again, the details of your privacy policy will depend on your app and your data practices, including what data from restricted scopes you collect and use.

Additional Limits on Use of Your Google User Data: Notwithstanding anything else in this Privacy Policy, if you provide the App access to the following types of your Google data, the App’s use of that data will be subject to these additional restrictions:

  • The App will only use access to read, write, modify or control Gmail message bodies (including attachments), metadata, headers, and settings to provide a web email client that allows users to compose, send, read, and process emails and will not transfer this Gmail data to others unless doing so is necessary to provide and improve these features, comply with applicable law, or as part of a merger, acquisition, or sale of assets.
  • The App will not use this Gmail data for serving advertisements.
  • The App will not allow humans to read this data unless we have your affirmative agreement for specific messages, doing so is necessary for security purposes such as investigating abuse, to comply with applicable law, or for the App’s internal operations and even then only when the data have been aggregated and anonymized.
How can I submit feedback about these policies and changes?

You can submit feedback to: oauth-feedback@google.com. The verification team will review feedback, but will not respond directly to submissions.

Was this article helpful?
How can we improve it?