Frequently Asked Questions

Navigate to a section to view the related frequently asked questions.

• Verification Process
• Cloud Console Configuration
• Unverified App Warning
• Service Accounts
• IMAP / SMTP
• Privacy Policy
• Limited Use
• Security Assessment
• Internal-only apps

The Verification Process

What are the different types of verification that Google requires for accessing user data via OAuth? 

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

What happens if my app gets rejected from the verification process?

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.

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.

Cloud Console Configuration

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

How do I check my user cap status?

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

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 Google Workspace 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 Google Workspace domain, you can mark it as internal-only in the OAuth consent screen configuration:

1. Go to the Cloud 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 User 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 Cloud 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 or doesn't exist, 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.

Unverified App Warning

Why are users seeing the Unverified App Screen or "Sign-in with Google temporarily disabled"?

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.

Why are users of verified and approved apps seeing the unverified app screen or "Sign-in disabled"?

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.

Service Accounts

How can I access data from my users' Google Cloud project using Cloud APIs?

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

IMAP / SMTP

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

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://www.googleapis.com/auth/gmail.send scope instead.

Privacy Policy

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

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.

Limited Use

Can I use Google User Data for generative artificial intelligence purposes?

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.

How do the Limited Use clauses apply to machine learning and artificial intelligence?

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.

What is a personalized model versus a foundation/generalized model?

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.

Security Assessment

How is my application tier calculated?

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

If I am in scope for Tier 2, but I don’t want to scan my own application, what should I do?

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.

Can my tier change?

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

Why is Google charging a fee for the security assessment?

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.

If I have gone through a security assessment once for restricted 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, it will still be required to get an annual reassessment. For more information,  check the CASA revalidation requirements.

How do I prepare for my annual security reassessment?

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

What access is needed by the third-party security assessor for the Deployment Review?

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.

Does the annual security reassessment only test changes I’ve made to my application since the previous assessment?

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

What happens if I don’t remediate my vulnerabilities?

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.