OAuth API Verification FAQ

Last modified on: June 12, 2019

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

Expand all Collapse all  

General Verification Process

The following FAQs apply for sensitive and restricted scope verification.

What are the different types of verification that Google requires for accessing user data via OAuth?
Type of verification Why this is needed Expected end-to-end time*
Brand verification Ensure that an app accurately represents its identity and intent per the Google API policy via verifying icon, display name, URLs, domain ownership, etc. 2-3 days
Sensitive scope verification Ensure that an app’s usage of sensitive scopes is not deceptive to protect user data per the Google API policy. 3-5 days
Restricted scope verification and security assessment Ensure that an app does not misuse user data obtained using restricted scopes per the Google API policy and the Additional Requirements for Specific API Scopes. Security assessment is required for apps that store (or transmit) data via servers. 4-8 weeks

*End-to-end time will vary based on developer responsiveness.

For information about what happens if you don’t submit your app for verification, see What happens if I don't submit my app for review? For information about what happens when you don’t need to submit your app for verification, see When can I skip submitting my app for a review? The three types of verification listed in the preceding table can be done individually or combined if you have added or modified the app’s branding information, requested sensitive scopes, and/or requested restricted scopes.

When does my app have to be verified by Google?

Your app might need to go through verification if:

  • Your app uses any of the sensitive or restricted 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 exceeds the domain count limit for a project.
  • There are changes to the OAuth consent screen after your app has been approved.
When can I skip submitting my app for a review?

You do not need to submit your app for review if it's 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. Learn more about public and internal applications. If you aren't an Apps Script developer, learn how to mark your app as internal in the FAQ How can I mark my app as internal-only?
  • The app is domain installed or whitelisted by a G Suite domain administrator. If your app is intended for G Suite users, access might depend on domain administrator permission. Obtaining a verification will likely make it easier for administrators to grant access.
  • The app is in development mode and not ready to be public. Note that the app will be subject to the OAuth user quota.
  • 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.
How long will the verification process take?
The sensitive scope app verifications are expected to take 3-5 days to account for clarification questions and re-submissions. Note that the restricted scope verification will take longer to complete, likely several weeks. User access to the app for existing approved scopes will not be impacted during the verification process.
How can I mark my app as internal-only so it doesn't require verification?

If you're an Apps Script developer, and the project owner is using a G Suite account and the project is only used by Google Accounts in the project owner's domain, then your project is automatically internal-only. Learn more about OAuth Client Verification Applicability.

If your app is only for your organization or G Suite domain, you can mark it as internal-only in the OAuth consent screen configuration:

  1. Go to the GCP Console OAuth consent screen page.
  2. Click the Project selector drop-down at the top of the page.
  3. On the Select from dialog that appears, select your project.
  4. Under Application type, select Internal, and then click Save.

If you don't see this option, then your project might not be part of an organization. To determine if your project is part of an organization:

  1. Go to the GCP Console IAM & admin Settings page.
  2. Click the Project selector drop-down at the top of the page.
  3. On the Select from dialog that appears, select your project.
  4. The Location section displays your project's location in its Organization. If the section is blank, then your project needs to be migrated to an Organization. Learn more about public and internal apps, how to use Organizations, and how to migrate your project to an Organization.
Who can submit a project for verification?

Only project owners and editors can submit a project for verification.

How do I submit for verification?

Before you submit for verification, make sure you understand the verification requirements:

To submit for verification, follow the steps below:

  1. Go to the GCP Console OAuth consent screen page.
  2. Click the Project selector drop-down at the top of the page.
  3. On the Select from dialog that appears, select your project.
    • If you can't find your project, and you know your project ID, you can construct a URL in your browser in the format https://console.cloud.google.com/apis/credentials/consent?project=[PROJECT_ID] where [PROJECT_ID] is the project ID you want to use.
  4. Enter the information required on the configuration page, and then click Submit for verification.
  5. In the Verification required dialog that appears, enter the appropriate justifications, and then click Submit to start the verification process.

Learn more about verification status.

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, see 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.

How can I check if I already submitted my app for scope verification?

To check your project's verification status:

  1. Go to the GCP Console OAuth Consent Screen configuration page.
  2. Click the Project selector drop-down at the top of the page.
  3. On the Select from dialog that appears, select your project.
    • If you can't find your project, and you know your project ID, you can construct a URL in your browser in the format https://console.cloud.google.com/apis/credentials/consent?project=[PROJECT_ID] where [PROJECT_ID] is the project ID you want to use.
  4. If you have submitted your project and it's currently in review, Being verified will display under Verification status. For more information about other verification statuses, see the User consent page.
How can I make sure the verification process is as streamlined as possible?

To ensure a streamlined verification process, please ensure that all the required information is included, such as the following:

  • 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.
  • Make sure that your application homepage links to an externally accessible domain that describes the necessary content, context, or connection to the app that you are submitting.
  • Make sure 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.
  • Make sure 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.
  • Make sure 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 require that 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.
What information should I include in the in-app testing video?

Please ensure that the YouTube link to a demo video demonstrates the OAuth grant process by users and explains the usage of sensitive and restricted scopes within the app’s functionality for each OAuth client belonging to the project.

  • Note that the video must clearly show the app's details such as the app name, OAuth Client ID, etc. as applicable.
  • The demo video must 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 to be productionized, we will be unable to complete our review and your request will be rejected. We require that you separate your testing/development and production projects. Our teams will thoroughly review your apps.

You can review the following guides on how to make a screencast on your Mac or PC:

What happens if I add new sensitive or restricted scopes to my app while my sensitive or restricted scope verification is in progress?

You can add new sensitive or restricted scopes in the GCP Console OAuth consent screen config page and click Submit for Verification. However, we will only approve those new scopes along with your existing sensitive or restricted scope verification. If you begin to use the new sensitive or restricted scopes before they are approved, users will experience the unverified app screen and the app will be subject to the 100-user quota.

For the restricted scope verification when a security assessment is required, verification is complete only after the security assessment is complete and you have provided evidence via a Letter of Assessment.

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.

What happens if I don't submit my app for review?

If you don't submit your app for review:

  • If your public app uses sensitive or restricted scopes that permit access to certain user data, users of your app might see an Unverified App screen.
  • To protect users and Google systems from abuse, apps 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.

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.

The app verification process can take anywhere from 3 to 5 business days.

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

Starting early next year, the following Drive scopes will also become restricted scopes. You do not need to submit for Drive restricted scope verification before then, but you'll need to go through the existing Drive sensitive scope verification if you have a production app and haven’t already done so. For more information, see the FAQ “How can I prepare for the Drive restricted scope verification that is taking effect early next year?”

  • https://www.googleapis.com/auth/drive
  • https://www.googleapis.com/auth/drive.readonly
  • https://www.googleapis.com/auth/drive.activity
  • https://www.googleapis.com/auth/drive.activity.readonly
  • https://www.googleapis.com/auth/drive.scripts
  • https://www.googleapis.com/auth/drive.metadata
  • https://www.googleapis.com/auth/drive.metadata.readonly
What is the restricted scope app verification and how is it different from the sensitive scope app verification?
How can I prepare for the Drive restricted scope verification that is taking effect early next year?

If the app needs to use the new restricted scopes to prepare for the restricted scope verification early next year, you can do the following now to ensure a smooth verification process in 2020. For apps that have already been approved for the Drive scopes, there is no need to submit for verification early next year. The app will need to reverify under the restricted scope verification at that time. For new apps that haven’t been approved for the Drive scopes, you need to undergo the existing sensitive scope verification early next year in order to use those scopes.

  • If your app is for internal organization usage only, be sure to mark the app as internal. For instructions, see the FAQ How can I mark my app as internal-only?. Public enterprise apps that request restricted scopes and are used by other enterprises are affected by this policy change and will need to submit their app for verification when the verification opens early next year. Regardless of whether an app requires verification or not, G Suite administrators are in control of their users’ apps and can whitelist apps as needed for their businesses.
  • Ensure that project owner and editor email addresses are up to date so that Google can communicate important policy updates and impact related to a developers’ app with the developer. Ensure that project support emails are up to date so that users can contact the developer as needed.
  • Remove any unused and test clients from the project before requesting verification.
  • Ensure that all scopes that your Google API project uses appear in your project's OAuth consent screen scope configuration in the Google API Console. For instructions, see the User consent section in the "Setting up OAuth 2.0" help article.
  • Ensure that your scope usage is as narrow as possible, and be prepared to tell us why a narrower scope is insufficient in the verification process.
  • 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 a third-party service provider owns your domain, 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 be compliant with the Google API User Data Policy and the Limited Use requirements. It 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.

Verification Process

How do I determine if I need to submit my app for restricted scope verification?

If you are using restricted scopes, you need to submit for verification. You do not need to submit for verification if any of the following applies to your project:

  • Your project uses Gmail Add-ons that doesn't use any of the restricted scopes.
  • Only owners use the project: if the project is only used by owners of the project, no action is required. To determine whether you are an owner (versus an editor or viewer):
    1. Go to the GCP Console IAM & admin page.
    2. Click the Project selector drop-down at the top of the page.
    3. On the Select from dialog that appears, select your project.
    4. Your roles are listed next to your email address in the Members list.
  • If you aren't an Apps Script developer AND the project is part of an Organization and is for internal use only: If the project owner is using a G Suite account and the project is only used by Google Accounts in the project owner's Organization, no action is required.
    • To determine if your project is part of an Organization:
      1. Go to the GCP Console IAM & admin Settings page.
      2. Click the Project selector drop-down at the top of the page.
      3. On the Select from dialog that appears, select your project.
      4. The Location section displays your project's location in its Organization. If the section is blank, then your project needs to be migrated to an Organization. Learn more about public and internal apps, how to use Organizations, and how to migrate your project to an Organization.
    • To indicate that the application is for internal use:
      1. Go to the GCP Console OAuth Consent Screen configuration page.
      2. Click the Project selector drop-down at the top of the page.
      3. On the Select from dialog that appears, select your project.
      4. Under Application type, select Internal, and then click Save.
  • If you are an Apps Script developer:
    • The project doesn't have users outside of your G Suite domain: If the project owner is using a G Suite account and the project is only used by Google Accounts in the project owner's domain, no action is required. Learn more about OAuth Client Verification Applicability.
    • To determine if you have an Apps Script that needs to be submitted for verification even if you have users outside of your G Suite domain:
      1. Open the script in the Apps Script editor.
      2. Select Resources > Cloud Platform project.
      3. In the dialog that appears, click the top link, which is typically something like [Script Name] - project-id-123456789012.
      4. If you can access the project using that link, then you need to submit for verification. If you don't see a link in the dialog and a message displays that "This script has an Apps-Script-managed Cloud Platform project", then you don't need to submit for verification.

If your project is used by Google Accounts outside of your organization, such as the general public, you need to submit your app for verification by February 15, 2019. For more information, see the FAQ How do I submit for verification?.

If you don't submit your existing projects for verification by February 15, 2019, then access for new users will be disabled on February 22, 2019, and existing grants for consumer accounts will be revoked on March 31, 2019.

My application has users with enterprise accounts from another G Suite Domain. How does this apply to my G Suite or Cloud Identity enterprise accounts?

You can skip the verification process if your app is solely built for G Suite customers and if the customers’ domain admin whitelists your app by completing the following steps:

  1. Make sure your project is marked as Public on the OAuth consent configuration page on Cloud Console.
  2. Ask your customers' domain admin to whitelist your app so that unverified app UI will not be shown to users on that domain. Note that G Suite administrators for those enterprise accounts can control which applications their users can access.
  3. Note that the following users will still experience the unverified app UI and eventually a user cap will be enforced:
    • Users trying to access the app from any domain that hasn’t explicitly whitelisted your app
    • Consumer users trying to authorize access to your app

If your application doesn’t fit the usage pattern in the preceding description, then you need to submit your application for verification. If you allow only enterprise accounts to use your app, be prepared to provide us with a sample enterprise account for verification purposes.

How will enterprise admins know that my app has completed a security assessment?

As a benefit for enterprise admins and developers, when your app has completed a security assessment, a badge will be added to your G Suite Marketplace listing.

What if my app is using IMAP or SMTP? Do I need to submit for verification?

Yes, because IMAP and SMTP usage require using https://mail.google.com/, you will need to submit your app for the restricted scope verification. If your usage of IMAP/SMTP is deemed to violate the minimum scope policy within the verification process, you will need to migrate to using the Gmail API by September 15, 2019.

What are the key dates for Gmail restricted scope application verification?

For apps that passed 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. All apps that have applied are expected to fully complete the app verification process by June 26, 2019 with the remainder of 2019 to complete the security assessment. If apps are unable to meet the June 26, 2019 deadline, new account access will start being disabled on June 27, 2019 and existing grants revoked starting on July 15, 2019.

To ensure that your app can complete the verification process by June 26, 2019, you must complete all outstanding issues from the Trust and Safety team and let them know by June 3, 2019. Users and enterprise admins may be notified of your app’s non-compliance as early as May 15, 2019. 

How long will the verification process take?

App verification is 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 June 26, 2019, with the remainder of 2019 to complete the security assessment. Users and enterprise admins may be notified of your app's non-compliance as early as May 20, 2019.

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

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.
What are the requirements for verification?

Homepage requirements

  • Your homepage must link to an externally accessible domain that describes the necessary content, context, or connection to the app you are submitting.
  • Your homepage must not be a link to a sign-in page.
  • Your homepage must explain with transparency the purpose for which your application requests user data.
  • Your homepage must thoroughly describe how your app enhances user functionality.
  • Your homepage must be accurate, inclusive, and easily accessible to all users.
  • Your Privacy Policy must be accessible from your homepage URL and visible to users. The Privacy Policy must clearly disclose the manner in which your application accesses, uses, stores, or shares Google user data.

Verified domains and accessible URL/URL links

You must verify the domain ownership for all authorized domains listed in your request:

  • Go to the Search Console to complete the domain verification process.
  • The account you use must be either a Project Owner or a Project Editor of your project.

Scopes selection and justification

  • Your requested scope(s) must be as granular as possible (if your requested scope goes beyond the usage needed, then we will either reject your request or suggest a more applicable scope).
  • You must provide a detailed justification for your requested scope(s) as well as an explanation for why a narrower scope wouldn't be sufficient. Example: My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app, so that users can manage their schedules through my app and sync the changes with their Google calendar.

App demonstration video

You must provide a YouTube link to a video, in English, that fully demonstrates the OAuth grant process by users and shows, in detail, the usage of restricted/sensitive scopes within the app’s functionality for each OAuth client belonging to the project.

  • The video must clearly show the app's details such as the app name, OAuth Client ID, etc. as applicable.
  • The demo video must show usage of sensitive and restricted scopes on each OAuth client.
  • Including the video along with the verification request will speed up the approval process significantly. We will not grant approval if you don't adequately explain scope usage on each OAuth client ID.
  • Additionally, if any of your OAuth clients, in the project requesting verification, are not ready to be put into production, we will not be able to complete our review and your request will be rejected. We require that you separate your testing/development and production projects. We will thoroughly test your apps.

Failure to satisfy/provide the preceding information might result in a rejection of your request. To avoid this outcome, update the applicable information in your request to meet our requirements.

Security assessment

If your application is sending or has the ability to send Google user data from a Restricted Scope to remote servers, then our verification process requires that your app undergo a security assessment to demonstrate a minimum level of capability in handling data securely and deleting user data upon user request. Depending on the scope and complexity of your app, the cost for the third-party assessment might vary from $15,000 to $75,000.

Apps not applicable for verification

  • Apps for internal use only (single domain use)
  • Apps for personal use only
  • Apps that are Gmail SMTP plugins for WordPress
  • Apps that are in development or staging/testing
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.

Application Types

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

What type of applications are not allowed to use the Restricted Scopes?

The following application types are examples of apps that are no longer allowed per the Permitted Application Types policy:

  • Mobile keyboards.
  • Applications that export email on a one-time or manual basis.
    • Applications that continuously and automatically backup email are permitted.
  • Apps that store or backup data other than email messages in Gmail.
  • Security apps, including those that scan for malware or identify spam or phishing emails.

Limited Use Requirements

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, re-targeted 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.]
    and
  • 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 is an example of language showing that my privacy policy complies with the Limited Use requirements?

The following is an example of language that might be appropriate if your app uses data from restricted scopes and is a web email client app.

You might 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 might 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. 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.
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, 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.

How can I make my privacy policy compliant with the Limited Use Requirements?

We can’t tell you what your privacy policy should say because it will largely depend on your specific data practices. However, if your privacy policy describes practices that may violate the Limited Use Requirements because it uses broad definitions of data that would include restricted scope data, then you may choose to provide a more specific disclosure demonstrating compliance with our policy. Again, how such disclosures are implemented is up to you and will depend on your practices. You may want to consult with legal counsel.

By way of example, explicitly stating how your app treats Google user data consistent with Google policies through a public web-accessible disclosure (such as an in-product disclosure on the application homepage, or public FAQ) is sufficient for completing verification. Such a statement in an FAQ accessible to users might say “App’s use of information received from Gmail APIs will adhere to Google's Limited Use Requirements.”

Note that you cannot complete verification if your privacy policy directly contravenes the Limited Use requirements. For example, if your privacy policy states, “App collects data from your electronic messages (email), and we share that data with our advertising partners for marketing purposes,” then your app cannot complete the verification process. This is true even if you disclose elsewhere in your product that your app follows the Limited Use Requirements.

Security Assessment

Why is the security assessment needed?

To help keep user data safe, we are requiring apps that store data on (or transmit data through) servers that are not fully managed Google services to demonstrate a minimum level of capability in handling data securely and deleting user data upon user request. Customers manage Google Cloud Platform and FirebaseCP services, so they would still require a security assessment. Google fully manages storing user data in Google Drive via drive.appdata, so this type of data storage does not require a security assessment.

How will the security assessment work?

First, your application will be reviewed for compliance with the Google API Services: User Data Policy via the restricted scope verification you submit through the GCP Console. Upon completing most of the checks in the restricted scope verification, you will receive an email with third-party security assessors who you can contact and use to perform your security assessment. You will have the remainder of 2019 to demonstrate compliance with the secure handling requirements. Please respond back to our email with letter of assessment before end of 2019 so your application can be fully approved for usage of restricted scopes.

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 if my app accesses Google user data through OAuth API Scopes that aren't Restricted API Scopes?

We strongly recommend that you work with the security assessor to demonstrate secure handling of all Google user data like Contacts, Drive, and Calendar that your app requests, even though these OAuth API scopes aren't considered Restricted scopes yet. Your app may be subject to future security assessment for these scopes.

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: Identifies, reduces, and prevents undesirable incidents or outcomes
    • Vulnerability Disclosure Program: Provides a means for external parties to report vulnerabilities
    • Information Security Policy: Ensures that all users comply with rules and guidelines related to the security of the information stored digitally at any point in the network
    • Privacy User Data Detection: Ensures that users can delete their accounts and related user data by demonstrating an account deletion if relevant

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. A certified third party will complete the security assessment to ensure the confidentiality of your application. Depending on the scope and complexity of your app, the cost for the third-party assessment may vary from $15,000 to $75,000. Smaller apps will be on the lower end, while more complex apps will require more review and expense.

Existing assessments that meet the security assessment program standards might reduce the scope and cost of your review. The assessors will consider existing assessments in their review.

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, such as setting up a backup capability, 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.

If I have gone through a security assessment once for the restricted Gmail scopes, do I need to go through the assessment again when the list of restricted scopes expands?

In general, the security assessment must be done once a year. If your app has been using the same set of restricted scopes as when your app went through the security assessment, your app does not need to go through an additional assessment.

However, if your app only recently started requesting additional restricted scopes after the security assessment was completed, your app will need to go through an additional security assessment to ensure secure implementation of the new scopes. The additional security assessment should be smaller in scope.

I don’t have a vulnerability disclosure program for my app and it's a requirement for the security assessment. What can I do?

You will be required to have a vulnerability disclosure program as part of the security assessment. If you don't have one, you can set one up for free with HackerOne. Go to this HackerOne page to sign up for an account and select "HackerOne Response."

When is the security assessment not required?

The following scenarios do not require a security assessment.

Local Data Storage: If you don’t want to go through a security assessment, you need to change your server storage to local storage only. Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device (such as a computer, mobile phone, or tablet).

As an example, apps such as Deseat.me have migrated from server storage to local web-client storage, and as a result security assessment is no longer required for this app. It also increases the level of trust users may have with this app.

Fewer than 100 Users: If your app is intended for a small audience and your users are in direct interaction with you, your app will be granted access for up to 100 users with an unverified app screen.

Users are Enterprise Accounts: If only G Suite accounts use your app, a G Suite domain administrator can enable your app via domain install or whitelisting. Your app can also be listed on the G Suite Marketplace. Keep in mind that many enterprises value a third-party security assessment, and a completed assessment for the Restricted Scopes verification will provide a Security Assessment badge in your Marketplace listing.

No Restricted Scope(s) Requested: You can update your project so that it does not request any restricted scopes, thereby avoiding the security assessment requirement.

 

How can I ensure my app can complete the security assessment for the Gmail restricted scopes by December 31, 2019?

Partners must be engaged with security assessors by September 16, 2019 to meet the December 31, 2019 deadline. Starting the process after this date might put your application at risk of missing the deadline.

Google API Security Awards Program

What is the Google API Security Rewards Program?

Google API Security Rewards Program is a bug bounty program that Google offers in collaboration with HackerOne. It recognizes the contributions of security researchers who invest their time and effort in helping make apps using OAuth more secure.

The goal of the program is to identify and mitigate vulnerabilities in third-party applications accessing OAuth restricted scopes and to keep users, developers, and the Google OAuth API ecosystem safe.

What are the criteria for enrollment?

To keep developers and their users safe, OAuth apps that use restricted scopes and that have more than 50,000 users are automatically enrolled into the program after they have passed the security assessment requirement.

How does it work?
  • A researcher identifies a vulnerability in an in-scope app and reports it directly to the app’s developer via their current vulnerability disclosure process.
  • Developers are required to resolve qualifying OAuth vulnerabilities within 30 days of being notified of the issue. Vulnerabilities that exceed the expected time to resolution will be considered in violation of the SLA.
  • After the vulnerability has been resolved or has exceeded the SLA, the researcher can submit a claim for a reward from the Google API Security Rewards Program. This is in addition to any reward that the app developer may independently offer.
  • HackerOne's role is to validate that submitted vulnerabilities meet the requirements for the rewards program. They will coordinate directly with the developers to verify that the details of the reports are accurate and that the vulnerabilities have been resolved.
  • HackerOne will notify Google of apps with ongoing SLA violations.
What happens if I don’t comply with the established program SLA?

If the developer exceeds the SLA in fixing qualifying vulnerabilities, Google may suspend an app’s access to Google APIs.

What happens if I don’t fix a reported bug?

If a critical vulnerability is not resolved within a reasonable amount of time, your use of the API may be suspended due to failure to comply with the “maintain a secure operating environment” requirement in the Google API Services User Data Policy.

Feedback

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 helpful?
How can we improve it?