Google OAuth Verification

The Data Access Page Is Where Google Compares Your Words To Your Code

Your app works. Your scopes are granted. And your users still see an "unverified app" screen — or your verification submission comes back asking questions you thought you had already answered.

Most of the time nothing is broken in your code. What is broken is the relationship between the scopes you declared in the Google Cloud Console and the scopes your app actually sends to Google's OAuth 2.0 endpoint. Google treats that as one system. Developers treat it as two.

The Google Cloud Console page formerly known as the "Scopes" section of the OAuth consent screen now lives under Google Auth Platform as the Data Access page. It is not a form you fill in once and forget. It is the declaration Google's Trust & Safety reviewers hold your app against — and the declaration Google's runtime checks against on every single authorization request.

When the two lists disagree, the failure is silent, delayed, and easy to blame on the wrong thing.

The rule, in Google's own words

This is not an interpretation or a community best practice. It is written policy:

"Your project configuration in the Google Cloud Console Consent Screen page must match the list of scopes requested by your app."

Google — OAuth 2.0 Policies (last modified December 15, 2025)

And the production-readiness guidance says the same thing from the other direction:

"Declare all scopes used by your app in the Cloud Console's Data Access page. Scopes you specify are grouped into sensitive or restricted categories to highlight any additional verification that's required."

Google — Sensitive scope verification (last updated 2026-03-22 UTC)

Two sentences. An enormous amount of failed integration time hides behind them.

What actually happens when the lists disagree

This is the part that surprises teams: a mismatch does not throw a clean error. There is no scope_not_declared response. Google's documented consequence is a user-facing screen and a hard growth ceiling.

Scope in code, not in console

Google states plainly: "When the scopes requested in your app code differ from the scopes requested in your OAuth consent screen configuration page, your users see an 'unverified app' screen." Your app keeps working — for the first hundred people.

Scope removed from console, still in code

"Using an unregistered scope, even if previously verified, will result in the user seeing the unverified app warning screen." Past approval does not protect a scope you have since deleted from the declaration.

New scope shipped before approval

"If you add new, unapproved scopes to your production app's codebase and start making API calls before these scopes are approved for your app, your users will start to see an unverified app warning pop-up."

The consequence you feel commercially

  • Google's documented cap on apps that present the unverified app screen: "100 new users in total, after the app presents the unverified app screen."
  • The screen appears before the consent screen — so the drop-off happens before the user ever sees what you are asking for.
  • Nothing in your logs says "scope mismatch". Your OAuth flow returns a token. Signups just stop converting.
  • Google also warns that a change in scopes or clients after approval "might have to go through verification again."

Why this is so much harder than it reads

The rule is one sentence. Complying with it across a real codebase is not, and this is where in-house teams lose weeks.

1

Your app rarely has one scope list

Google's own instruction is "examine your app's source code for any scopes sent with authorization requests" — plural, everywhere. Web flow, mobile flow, background jobs, an old admin tool, a client SDK default. Every one of them contributes to what Google sees at runtime.

2

Copied example scopes are almost always too broad

Google names this failure mode directly: proof-of-concept example scopes "often request more information than the final implementation of your app needs" — read, write and delete when you only ever read. That single copied constant can move you from non-sensitive into a review queue.

3

Incremental authorization quietly widens the request

include_granted_scopes=true reattaches previously granted scopes. Google's caution: "A warning or error page may be displayed if your app is not currently approved to request all scopes that may be returned in the response."

4

Every sensitive scope needs a justification that survives challenge

Not a sentence. Google wants "An explanation why narrower scopes would not work, including specifics on what functionality would not work as intended" — and warns "If your justification is deemed insufficient, your app verification request may be rejected."

5

The demo video is judged against the same list

"The consent screen must also show the same exact scopes you are requesting." The video must show the end-to-end flow, the OAuth grant process, the app name, the client ID in the address bar, in English, uploaded unlisted. A video recorded before your last scope edit is now a mismatch of its own.

6

Ordering matters and is not obvious

Google: "You must have a published branding status before you can request verification for data access (scopes)." Branding status and data access status are tracked separately. Teams routinely submit in the wrong order and wait on a queue they were never in.

The one sequencing rule that saves the most pain

Google's note on adding a scope to an already-verified app: "do not immediately include this scope in the list of scopes in your request to the Google OAuth 2.0 endpoint until it is verified, else users will see an unverified app warning screen." The recommendation is explicit — "get your app verified and approved for the new scopes, before making code changes to use the scopes." Most teams ship the code first. That order is backwards, and it costs a live user cap.

The narrowest-scope test you will be measured against

Declaring accurately is necessary but not sufficient. Google applies a second filter to whatever you declare:

"You must only request the narrowest scope(s) your app needs to function." … "Do not request access to data based on 'future enhancements' that has not been implemented yet in your app."

Google — OAuth App verification requirements

And the outcome if you overreach: "If the requested scope(s) goes beyond the usage needed, you will be directed to request a narrower scope to proceed with verification." That is another full round trip — new scope, new code change, new video, new submission.

Where submissions actually come apart

  • An SDK default nobody declared. A library requesting a broad scope you never wrote down, discovered only when users report the warning screen.
  • A deleted scope still living in a config file. Removed from the console during a cleanup, never removed from the request.
  • A justification written for the API, not for the feature. Google's acceptable example ties a specific scope to a specific screen and a specific user outcome. Generic descriptions get challenged.
  • A stale demo video. Consent screen in the recording no longer matches the current declaration.
  • Multiple OAuth clients in one project. "Your video must include all OAuth clients that you assigned to this project." Half-finished test clients drag the whole submission down — Google's own suggestion is to delete clients that "aren't ready for production."
  • No graceful handling of denied scopes. Policy requires it: "If a user doesn't grant a scope that you requested, you need to disable any related functionality in your app and not make any related API calls that will fail."

What a clean submission looks like

An audited scope inventory taken from the code rather than from memory. Each scope reduced to the narrowest one that still powers a shipped feature. A per-scope justification written against a visible user outcome. A Data Access declaration that matches the code exactly, character for character. Branding published before data access is submitted. A demo video recorded after the declaration is frozen, showing the same exact scopes. And a rollout order that puts approval before deployment, not after.

That is the work. It is unglamorous, it is detail-bound, and one wrong string anywhere in it puts you back at the start of a queue.

Related reading

Policy statements above are quoted from Google's public documentation (OAuth 2.0 Policies, OAuth App verification requirements, Manage App Data Access, Unverified apps, Sensitive scope verification) as retrieved on 1 August 2026. Google updates these pages; always confirm against the current version before you submit. This page is independent guidance and is not affiliated with, endorsed by, or a partner of Google LLC.