Google's OAuth consent screen

If you're using any of Google's APIs that enable access to sensitive or restricted user data, you'll have to prepare for a verification through Google's review team about what and why data you're accessing, as detailed here. Only after your submission has been verfied, your app's part that shows the consent screen should be made public.

If no successful verification was done, users will see a warning before providing permissions to your app. Your application will be described as a potential security threat in the displayed dialog! You really don't want that to happen, so a verified consent screen by Google is just a requirement.

So let's read on to learn how to best prepare for your verification.

Start now

Even if you don't have the frontend and/or backend yet implemented, you can already prepare for the verfication process by proofing that you're the owner of the production domain, e.g. that www.company.com really is your domain.

If you haven't setup a project in GCP (Google Cloud Platform), do so now. Every subsequent step presupposes a valid GCP project for your account.

To verify the ownership, just follow Google's guidelines. As an example, I set a provided TXT record containing a UID for Google to be used as verification.

👉 See guidelines

👉 See GCP info

The review begins

After your domain ownership has been verfied, you'll have to provide some more data such as application name & logo as well as URLs to the app's homepage as well as privacy.

Note that if the actual app is hosted under a subdomain (e.g. app.company.com), you'll still have to provide a link to the privacy-url at your main domain (e.g. company.com) as well as the subdomain.

Before the review can start, a list of all API-scopes has to be provided. Take special care in selecting only the scopes you really require. As an example, it's unecessary to define auth/calendar, which gives you both full read and write access to the user's calendar if you only want to read events, which can be accomplished with auth/calendar.events.readonly as well.

To be really clear about your intent on what to do with the data, Google requires each verification request to be complemented by a detailed description why each scope is needed and how it will be used in your application.

If everything is set in place, you can kick-off the review!

👉 See general info

👉 Check all available scopes

Let's direct a movie

It may take a few business days until you receive an email from the review team. If no problems were found, you'll be asked to provide a link to a YouTube-video demonstrating the complete user-flow from granting permission via the Google OAuth consent screen to using each scope in your app.

Make sure to screencast your whole screen. Only casting the browser window might not be sufficient, as the consent screen is displayed as pop-up.

Take care that everything is clearly visible. Only upload at least 1080p footage to YouTube so that details can be seen.

Important: When the consent screen is visible, make sure that the url-param client-id is documented in the video. If necessary, widen the view's window and manually select the client-id in the url with your mouse cursor. That way, the review team clearly sees that your app uses the correct consent screen.

If your app doesn't implement English text, make sure to provide at least English translations.

👉 How to create cast on macOS

👉 How to create cast on Windows

That's about it!

Preparing for your review thoroughly and taking a detail-oriented approach is all that's required to make your OAuth consent view's verification easy and fast.

After the successful review, your users will see a valid consent screen they can trust and continue to use your app.

Thanks for reading!

- Tom