Frequently Asked Questions

There are three types of verification that Google requires to access user data via OAuth. 

Type of Verification	Purpose	Expected time of completion*
Brand Verification	Ensure that an app accurately represents its identity and intent per the Google API policy by verifying the logo, display name, URLs, domain ownership, etc.	2-3 days
Sensitive Scope Verification	Ensure that an app’s usage of sensitive scopes is not deceptive and in alignment with the appropriate use case, limited use, and minimum scope requirements, to protect user data  per the Google API policy and the Additional Requirements for Specific API Scopes.	10 days
Restricted Scope Verification	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. An additional Ssecurity assessment is required to demonstrate a minimum level of capability in handling data securely and deleting user data upon user request.	Several weeks

 

* Please note that these estimates are not guaranteed and will vary based on developer responsiveness

If the app has been rejected for sensitive or restricted scopes, users’ access to the unapproved sensitive or restricted scopes in the app via OAuth will no longer work.

If you want to reapply, do the following:

1. Ensure that your app complies with our policies. For more information, see Verification Requirements
2. On the Cloud Console OAuth consent screen page, select the sensitive or restricted scopes you’re requesting access to and click Submit for Verification. All required materials need to be resubmitted.

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.

You can add new sensitive or restricted scopes in the Cloud Console OAuth consent screen config page and click Submit for Verification any time. However, if your app starts 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 cap.

Please note the user cap applies over the entire lifetime of the project, and it cannot be reset or changed. You can check your user cap with the following these instructions:

1. Sign in to Google Cloud Console
2. Select your project-id 
3. Go to OAuth Consent Screen under APIs & Services
4. Go to OAuth user cap and check your user cap usage status

Failure to get your app verified for sensitive and/or restricted scopes might result in exhaustion of your project's 100-user cap and cause Google sign-in to be disabled. Learn more about Unverified apps

To protect users and Google systems from abuse, unverified apps that are accessing restricted or sensitive scopes have a 100 new-user cap restriction. Failure to get your app verified before making requests to sensitive or restricted scopes will result in your project's 100 new-user cap eventually getting exhausted and Google sign-in being disabled for your users. Learn more about Unverified apps.

This is caused by approved apps making requests to sensitive or restricted scopes that the app has not been approved for during the verification process. Review the approved scopes in your Cloud Console for the project and make sure that the codebase of your app is not requesting any scopes that are not listed in your GCP project.

If you need assistance with identifying which unapproved scopes your project is requesting, reach out by directly responding to the last email that the verification team sent you. After the scopes are identified, do the following:

• If the scopes are not needed, remove requests for the scopes from your codebase.
• If the scopes are needed, add them to the Cloud Console and submit them for verification. The scopes needs to be approved prior to making calls to them.

Why are users of apps that are currently in the verification process seeing the unverified app screen or "Sign-in disabled"?

This is caused by the project actively making requests for restricted or sensitive scopes that have not yet been approved/verified. If you need assistance with identifying which unapproved scopes your project is requesting, reach out by directly responding to the last email that the verification team sent you. After the scopes are identified, do the following:

• If the scopes are not needed, remove requests for the scopes from your codebase.
• If the scopes are needed, add them to the Cloud Console and submit them for verification.

You can access data from your users' Google Cloud 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:

• Using OAuth 2.0 for Server to Server Applications
• Service Accounts

IAM Policies:

• IAM Policies
• IAM Quickstart

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

Yes, because IMAP and SMTP usage requires using https://mail.google.com/, you will need to submit your app for the restricted scope verification for this determination. 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.

If your app uses IMAP protocol or joint IMAP/SMTP protocols, note that the https://mail.google.com/ scope should only be requested if your application also needs to immediately and permanently delete threads and messages, bypassing Trash; all other actions can be performed with less permissive scopes. If your app does not do this, you will need to migrate to the Gmail API and request less permissive scopes.

If your app uses SMTP protocol only, note that using the broad access https://mail.google.com/ scope just for sending emails with the SMTP protocol violates the minimum scope policy. To use the Gmail API and continue with the verification process, you will need to migrate off SMTP protocol and use the sensitive https://googleapis.com/auth/gmail.send scope instead.

Only data from restricted scopes needs to comply with our Additional Requirements for Specific API Scopes.

The exact wording of your privacy policy will largely depend on your specific data practices, including how you use, store, or transfer other data you collect. We recommend seeking legal advice on what's right for your app.

If you use broad terms in your privacy policy to refer to data from sensitive/restricted scopes and other types of data, we will interpret your disclosures as applying to user data from sensitive/restricted scopes. Where possible, you should refer to data from sensitive/restricted scopes separately in your privacy policy. For example, if your app uses data from sensitive/restricted scopes, as well as other data obtained from your users in your app, you can separate your disclosures on how you use those different sources of data.

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

Describing how your app uses 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 enough for going through the verification process.

For example, your public FAQ could contain a statement like the following:

“{App’s} use of information received from Google APIs will adhere to Google API Services User Data Policy, including the Limited Use requirements.”

For more information about the Limited Use disclosure requirements, see Verification Requirements.

Google’s API Terms of Service prohibit scraping, storing, or otherwise making permanent copies of Google User Data without explicit consent. The Workspace API User Data and Developer policy also prohibits Google User Data from being used to create, train, or improve a machine learning or artificial intelligence model, including foundational models. Google User Data may not be used to train or improve foundational models or be stored in conjunction with foundational models.

For purposes of the Workspace API Policy, the Limited Use section allows transfers of data to provide or improve the user-facing feature or user-directed appropriate use case of the app. In the context of AI/ML this means Google User Data must be used only for a personalized model to execute a user-facing feature or the user-directed appropriate use case. Google User Data may not be used to train or improve foundational or frontier models or be stored in conjunction with such models.

For purposes of the Workspace API Policy, personalized models include any models run exclusively on-device or a model specifically tailored to only that end user or organization. Personalized models do not co-mingle Google User Data with other end users or organizations. In contrast, Foundational, generalized, and frontier models include models trained on broad data or any model with Google User Data that is being used for purposes beyond the action directed by the user to perform the user-facing feature. In some instances, foundation models will include fine-tuned models or domain-specific models. In short, Google User data must only be used for personalized models and must not be stored in any other model.

Your application tier is calculated based on the: 

• Sensitivity of the data the application is accessing, Each data type is given a risk weight to affect the tier calculation
• The amount of users per type of data accessed
• Internal risk indicators

You can choose to reachout to the CASA authorized assessor and pay for the assessment. If you are in scope for the free tier 2 assessment and choose to reachout to the authorized assessors you will be required to pay the authorized assessor directly.

Yes, your tier depends on:

• Sensitivity of the data the application is accessing, Each data type is given a risk weight to affect the tier calculation
• The amount of users per type of data accessed
• Internal risk indicators

Google does not charge the developer any fees for security assessment.
Security assessments are conducted by CASA authorized independent security assessors.
The App Defense Alliance (ADA) provides industry standard based requirements against which the independent security assessor tests an app. 

The cost for such a service is agreed on between the developer and the assessor without any involvement from Google. We encourage our developers to reachout to multiple assessors to find what works best for them.

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, it will still be required to get an annual reassessment. For more information,  check the CASA revalidation requirements.

• Before your reassessment, your app will need to be reverified for compliance with the Google APIs Terms of Service, Google's API Services User Data Policy, the product specific User Data Policy (if applicable), and the Additional Requirements for Specific Scopes. The Trust and Safety team will contact you to get the reverification process started.
• After your app passes reverification, please reach out to any of the empanelled security assessors for details on the scope and cost of your reassessment. If you choose to go to another security assessor for your reassessment, you will need to share your report from the previous year with the new assessor.
• If you plan on adding or removing restricted scopes to your project during your security assessment, please notify your security assessor in advance and make the relevant changes to your Google Cloud Console. Scope changes during assessment might change the scope and cost. For more information, see What happens if I add new sensitive or restricted scopes to my app while my sensitive or restricted scope verification is in progress?
• If you have any additional projects that you would like to include in your Letter of Assessment, please be sure that those projects have gone through the OAuth verification process and that Google granted you eligibility to go through a security assessment. You should then notify your security assessor of these additional projects. You won’t be required to get a security assessment for projects with no restricted scopes.
• To receive an LOA, you must have remediated any critical or high findings from the current year’s assessment test, and remediate any mandatory SAQ findings.

For "Tier 3" assessments, the assessor will need read-only access to the cloud system where Google production data will be stored. More popular cloud providers such as AWS, GCP, and Azure provide read-only security auditor roles. The security assessor will use these roles to review configuration and deployment settings in production. The security assessor will also need read-only permission to all available security groups and clusters to run tools or scripts that analyze the security posture of the cloud environment. One popular tool that is often used by the security assessors is Scout Suite, which is free and can be run beforehand to preview results.

If you cannot provide remote read-only production access to the third-party security assessment, you may need to bring the third party assessor onsite for the assessment, or may choose to allow the third-party assessor to review the relevant configurations via a remote screen share/web conference. The remote screen share/web conference approach allows you to remain in control of the cloud system while the security assessor provides which commands to enter and reviews results. This approach will take more time and therefore will be a more costly assessment.

We require the annual security reassessment to be a complete test of your application whether you have made any changes or not.

If a critical vulnerability is not resolved within a reasonable amount of time or exceeds the time frame set by your assessor, 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.