OAuth Developer Verification Form FAQ

This article answers frequently asked questions about the OAuth Developer Verification form.

Expand all Collapse all  
  Why am I being asked to fill out this form?

To protect users and their data from deceptive applications, your new or updated web application or Apps Script may show an Unverified App screen prior to displaying the consent screen or may be shown as potentially risky to the user in Security Checkup.

You need to go through the verification process before you launch your application. Upon successful completion of the process, the Unverified App screen will be removed from your client and your app will no longer be marked as risky to users in Security Checkup. Verification process typically takes between 3 and 7 business days, but in some cases it may take longer.

Note: Subsequent modifications of your client or the usage of new scopes after verification may require you to go through verification again.

See our earlier blog post on accessing user data which outlines your responsibility when requesting access to user data from your application. Our teams will continue our constant efforts to support a powerful, useful developer ecosystem that keeps users and their data safe. For more details on the verification process, see the article Unverified App.

How can I ensure the verification process is quick and smooth?

Make sure you complete the steps below before submitting the verification request:

  1. Identify who requires the OAuth access tokens. If they will be used only to access accounts you or your development team own, you do not need to fill out a verification request. If they will be used to access accounts owned by others, you do.
  2. Your OAuth Consent Screen is created.
  3. Your authorized redirect URI or origin URL is linked to the OAuth web client.
  4. 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 Google Cloud 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 explicitly disclosed in your published Privacy Policy.
  5. Each scope that you're requesting in the form must have an explanation for its use/need for the project.
  6. Only request scopes that your app needs. Ensure that you are not asking for permissions that your app does not use. Each scope that you’re requesting in the form must have an explanation for its use/need for the project.
  7. Verify your application’s homepage URL domain ownership with Google through Search Console by using an account that is either a Project Owner or a Project Editor on your OAuth Project.
  8. Ensure the top level domains for all your URLs such as privacy policy URL, redirect URI, homepage URL should match with the verified domain that you own.
  9. Ensure all your redirect URIs are encrypted and secure. It can be done by using an HTTPS protocol (a secure, encrypted connection).
  10. Ensure all Oauth branding info on AppConsole such as project name shown to users, support email, homepage url, privacy policy URL, etc. accurately represents the app’s identity.
  11. If you use Google Sign-In Scopes in your app, please ensure that your app is compliant per these branding guidelines:
In what scenarios can I skip the developer verification process?

The Developer verification process will need to be completed to remove the Unverified App screen from your app or to remove your app from being shown as potentially risky to the user in Security Checkup. The Unverified App screen informs the user of that the app has not yet passed the verification process. You do not need to submit the developer verification form if your app is going to be used in any of the following scenarios:

  • My app is not shared with anyone else
  • This app is for me and my family/friends
  • I am using this for sending emails through Wordpress or similar single account SMTP plug-ins
  • My app is trying to access data from my users’ Google Cloud Platform Project
  • If the users of your non-apps scripts web clients belong to the same G Suite domain, and the project is associated with a Cloud Organization
  • If the owner and users of your Apps Scripts belong to the same G Suite domain or customer
  • I am using this app to allow users to sign-in to my platform using their basic profile information

However, if the above applies and you want to remove the Unverified App screen, you will need to continue with the verification process. To ensure your submission is complete, refer to the answer to the below question How do I ensure my verification request is approved at the earliest time possible?

For more information, see the Unverified App help article. Also, please see our blog post on new security protections to reduce risk from unverified apps.

What if my app is going to be used only by users within my domain?

If your app will only be used by users within your domain, you will need to associate your project with a Cloud Organization.

To do so, you will need to:

  1. Create an Organization (if you don't already have one) as instructed in Quickstart Using Organizations.
  2. Migrate the project into the organization you created, as described in Migrating Existing Projects into the Organization.

For support related questions, see Get Support.

My app allows users to sign in using Google, but I am seeing the Unverified App warning. How do I fix it?
You should not be seeing the Unverified App screen if you use Google Sign-In scopes to enable users to login to the platform. If your app is trying to use other any scopes along with Google Sign-In scopes, you may have to go through the verification process. For reference, a full list of all OAuth scopes can be found on the page OAuth 2.0 Scopes for Google APIs.
I have gone through the verification process. Why do I still see the Unverified App screen on my app? Why is my app listed as potentially risky app in Security Checkup?

Please note that any subsequent modifications of your client or the usage of new scopes after verification may require you to go through verification again. For more information, see the Unverified App help article.

What is a valid OAuth client ID and how do I find it? What is invalid or inapplicable Client ID?

Google APIs use the OAuth 2.0 protocol for authentication and authorization. Google supports common OAuth 2.0 scenarios such as those for web server, installed, and client-side applications. A client ID is a key associated with the client that is attempting to get access to the user's data.

To find an OAuth 2.0 client ID created for your project in the console:

  1. Go to the Google Cloud Console.
  2. From the projects list, select the project for which you want to submit the OAuth Developer Verification form.
  3. If the APIs & services page isn't already open, open the console left side menu and select APIs & services.
  4. On the left, click Credentials.
  5. Locate the client ID on the Credentials tab.

If you received a communication from us which indicates that client ID is either invalid or inapplicable, please refer following scenarios:

  • Invalid Client:
    • Client ID provided by you is either gibberish or deleted. Please submit another request through the Developer Verification Form with the correct client id and all other relevant information. 
  • Inapplicable Client: 
    • Non-web Client: Oauth Developer Verification process is currently applicable only for Web Clients thus if your client is Native App Client, Android or iOS App Client or any other non-web client then verification process is not applicable to your client.
    • Web Client for Chrome Extension: Best way to set up chrome extensions will be to create a client for Chrome extension client on Google Cloud Console and proceed with development. Doing this will ensure you do not have to go through this verification process and you can freely make changes to your app. Please refer this article on Setting up OAuth 2.0 for more details.
    • Localhost Client: If you want to use client for localhost usage, please visit the Google API Console to create a new OAuth client id with application type 'Other'.
What are Invalid or inapplicable scopes?

You may receive an invalid scope communication from us for following reasons:

  • Incomplete Scope Name: You have submitted incorrect names of scope while submitting the Oauth Developer Verification Form. Please provide the full name of the scopes and detailed further explanation of your planned use/need of each scope while submitting the Developer verification form. For reference, a full list of OAuth scopes can be found on the OAuth 2.0 Scopes page.
  • Inapplicable scopes: You may have submitted list of scopes which your app already has access to and verification process is not needed for them. If your app is using only Google Sign-in scopes, you do not have to go through the verification process. However, if you are still seeing the ‘unverified app’ screen, please provide a complete list of scope names your app is currently using and detailed further explanation of your planned use/need of each scope on the same email thread where you received this communication  for us to look into the issue.
I need help selecting scopes for my app. Where can I find support for various product APIs?

For help with deciding which scopes to use for your app, refer following Support pages.

What Drive API scope or scopes does my app need?

As a general rule, choose the most restrictive scope possible, and avoid requesting scopes that your app does not actually need. Users more readily grant access to limited, clearly described scopes. Conversely, users may hesitate to grant broad access to their files unless they truly trust your app and understand why it needs the information.

The scope https://www.googleapis.com/auth/drive.file strikes this balance in a practical way. Presumably, users only open or create a file with an app that they trust, for reasons they understand.

For more information, see What scope or scopes does my app need?, a guide on Google Drive API scopes.

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

You can access data from your users' Google Cloud Platform project by creating a service account to represent your service, and then having your customers grant that service account appropriate access to their Cloud data via IAM Policies. Note that you may want to create a service account per customer if you must avoid confused deputy problems. Please take a look at the articles below in order to familiarize yourself and educate your users on using service account and updating the Cloud IAM policies.

Service Account Creation:

IAM Policy:

If any of your users are having issues creating a service account or granting your project the appropriate permissions via the IAM Policies, please direct them to Google Cloud Support.

Can I use the redirect URI with top level and sub level domain belonging to third party product?
With the recent changes that we have made to the OAuth approval process, if you are using a redirect URI of a third party domain, the user will see an approval page showing that the third party domain is requesting the data. If they come to this page from your site, this could be confusing to your users. Thus to avoid confusion, the redirect domain must match your app's domain.
Is it possible to view all the scopes that have been verified for my client IDs?

Unfortunately you are unable to see the scopes that have been approved at this time. For now, you can create a number of OAuth requests each with one of the scopes to verify. We are working on a number of improvements and those will be rolling out through the rest of the year. Thank you for your patience.