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 VerificationWhat 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.
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
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 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.
- 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.
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.
If you need help deciding which scopes to use for your app, please refer to the OAuth 2.0 Scopes for Google APIs documentation.
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.
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.
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:
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 VerificationWhat 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.
All apps that request a restricted API scope need to submit for verification. This includes web, iOS, Android, and other native client types.
- Verification can be submitted from the Google API Console starting Jan 15th, 2019.
- The information needed include declaring your application type, an explanation for why each scope that you're requesting is needed for the project, and an agreement stating that your usage of restricted scopes comply with all Additional Requirements for Specific API Scopes.
- Along the with details mentioned above, please refer to How can I ensure the verification process is quick and smooth? before submitting your verification request.
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.
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.
- The sensitive scope app verification verifies compliance with the Google API User Data Policy.
- The restricted scope app verification verifies compliance with the Google API User Data Policy and an additional set of requirements for restricted scopes outlined in Additional Requirements for Specific API Scopes.
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.
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.
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.
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.
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.
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.
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.
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.
The security assessment includes the following.
- 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
- 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.
- 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
- 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.
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.
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.
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.
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.
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.
The Limited Use requirements have four elements:
- 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.
- 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.
- 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.
- 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).
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.]
Only data obtained from restricted scopes is subject to our Additional Requirements for Specific API Scopes.
- 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.
You can submit feedback to:
firstname.lastname@example.org. The verification team will review feedback, but will not respond directly to submissions.