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 asnd have its OAuth consent screen configuration verified by Google.
Your app may also need to undergo verification if:
- Your app displays an icon on the OAuth consent screen
- The number of authorized domains for your apps exceed the domain count limit for a project
- Your app uses any of the sensitive scopes to request Google User Data
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:
- 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 support page.
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.
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.
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. Starting March 31, 2019, only users with project owner, editor and viewer permissions (that is, the app developers) will get access to the app if you do not submit your app for verification.
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.
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 third party, 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. More details will be available in January 2019.
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.
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.
To provide clarity to developers, the following uses of data obtained from restricted scopes are not considered to be providing user-facing features.
- Aggregating data for market research purposes benefitting the developer or third parties
- Monitoring email campaign tracking for campaign senders
- Advertising for third parties
This list is not exhaustive. This article may be updated with additional examples in the future to clarify the allowable uses of data.
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.
Developers can submit questions to email@example.com. The verification team will review the questions and provide a response by updating this FAQ. In some cases, an email response may be provided on a best-effort basis.