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.
Make sure you complete the steps below before submitting the verification request:
- 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.
- Your OAuth Consent Screen is created.
- Your authorized redirect URI or origin URL is linked to the OAuth web client.
- Each scope that you're requesting in the form must have an explanation for its use/need for the project.
- 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.
- 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.
- Ensure all your redirect URIs are encrypted and secure. It can be done by using an HTTPS protocol (a secure, encrypted connection).
- If you use Google Sign-In Scopes in your app, please ensure that your app is compliant per these branding guidelines:
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?
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:
- Create an Organization (if you don't already have one) as instructed in Quickstart Using Organizations.
- Migrate the project into the organization you created, as described in Migrating Existing Projects into the Organization.
For support related questions, see Get Support.
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.
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:
- Go to the Google Cloud Console.
- From the projects list, select the project for which you want to submit the OAuth Developer Verification form.
- If the APIs & services page isn't already open, open the console left side menu and select APIs & services.
- On the left, click Credentials.
- 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'.
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.
For help with deciding which scopes to use for your app, refer following Support pages.
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.
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:
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.
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.