Google OAuth Verification: The Demo Video Script That Covers Every Requirement

We submitted Savra for Google's OAuth app verification this week. The submission form took twenty minutes. The demo video it requires took a full day of preparation, and preparing it taught us more about Google's OAuth model than two months of building against it.

The video is the heart of the submission. Justification text makes claims; the video is where a reviewer watches those claims run. Ours had to prove two OAuth flows, three data scopes in use on real accounts, and a working disconnect, in one unlisted YouTube link. Here is the scene list we recorded, the consent-screen traps that would have cost us the take, and what the form actually asks when you file.

What does the demo video have to prove?

Google's rubric is short and strict. The video must show the OAuth consent flow on your client ID, the sign-in flow too if you offer Google Sign-In, and each sensitive scope powering a real feature. The browser URL bar stays visible throughout, consent flows run uncut, and the narration or captions are English.

Two details in that list decide your edit. Uncut means the consent flow is one continuous take from button click to redirect; you can cut between scenes, never inside one. And the URL bar matters because the client ID in it is what the reviewer matches against your filing. Pause on it long enough to read.

Why did our video need two OAuth flows?

One OAuth client can serve more than one flow, and ours does. Savra's "Continue with Google" sign-in requests basic identity (openid, email, profile). The Connected Accounts flow, where a customer links Search Console, Analytics, and Ads, requests the data scopes. Same client ID, two consent journeys.

Your Data Access declaration is the union of every scope any flow requests. For us that union is six scopes, and one of them, the profile scope, appears only in sign-in. The tempting cleanup is to trim the declaration down to the data flow and call it tidy. That cleanup makes the declaration lie, because the sign-in flow really does request profile. The correct move is the opposite: declare the union, then show both flows on camera so every declared scope gets demonstrated. Our video opens with sign-in for exactly this reason.

What scene list did we record?

Seven scenes, assembled from separate takes with hard cuts between them.

Three production choices helped. We recorded in a clean incognito session so no personal accounts appeared in Google's chooser, and signed the accounts into Google off camera first, which absorbs any verify-it's-you challenge before the take instead of during it. We put scene timestamps in the YouTube description so a reviewer can jump straight to any scope. And the video is unlisted, which is what the form expects: reachable by link, invisible to search.

Which traps would have cost us the take?

The fresh-account trap. Sign-in flows built on prompt=select_account show consent only on a Google account's first-ever grant. An account that granted months ago sails through with nothing to film. Worse, "fresh" is slippery: auth providers commonly link sign-ins by email, so an address that once touched your app resurrects an old user instead of creating a new one. We picked an account that had never met the app, and kept a cleanup script ready so a retake could reuse the email. If you need consent to reappear for an account that already granted, revoke your app on that account's Google connections page first.

The unverified warning belongs on camera. Before approval, sensitive scopes trigger the full "Google hasn't verified this app" interstitial. Instinct says hide it. The submission form says the opposite, in writing: the unverified screen is expected and must be shown. Click Advanced, continue, keep rolling.

Your app name may not be the name on screen. While unverified, Google's consent screens display your domain rather than your registered app name. Ours read as the bare domain through the whole shoot, and that is correct pre-approval behavior, so we left it alone. Renaming branding mid-filing restarts a review you already passed.

The scariest scope text is not yours to soften. The Google Ads API exposes a single OAuth scope, and Google describes it as "see, edit, create, and delete your Google Ads accounts and data" no matter what your app does. You cannot change the consent wording. You can, and should, address it head-on in the justification: reporting only, no read-only variant exists, the app never mutates campaigns. Write it before a reviewer has to ask.

Start the connect scene disconnected. If the account is already linked, the page shows management buttons and your narration about "connecting" stops matching the screen. We disconnected off camera, then rolled the take from the clean state so the story reads the way a new customer lives it.

Skip the Google-side proof shot. We considered ending on the account's Google connections page to show the app gone after disconnect. We cut the idea: a well-built disconnect revokes the Google grant only when it is that Google account's last connection to your app, so with a second workspace still linked the app rightly stays listed, and the frame reads as a failed revoke. Show the in-app disconnect and stop there.

What does the submission form actually ask?

The Verification Center walks branding, then data access. Three things surprised us.

Scope classification is Google's call, and it may not match your intuition. Our Search Console read-only scope turned out to be classified non-sensitive, so the justification field covered only Analytics and Ads. Check the lock icons on your Data Access page before you budget your words.

Justification is one field with a 1,000-character limit, shared across your sensitive scopes, and whatever a teammate typed there months ago is still what Google will read. Ours held an old two-line draft that never mentioned Ads. We replaced it with a version that named each scope, the narrowest-scope argument, and the Ads single-scope explanation. The video link gets its own required field, and there is a free-text box worth using: we spent it on a map of the two flows and a pointer at the timestamps.

The final questionnaire is a filter, and honesty is cheap. Four yes-or-no questions establish that the app is a real production product rather than personal, internal, or staging use, plus two acknowledgements. Then submit. Our status flipped to under review immediately, with first contact promised within 3 to 5 days and the full review quoted at up to 4 to 6 weeks. The consent screen keeps working throughout, and the form warns against switching publishing status or user type mid-review, so freeze what the reviewers are looking at until they answer.

The approval post, with what the reviewers actually checked, waits until the approval exists. That is the deal with writing these as they happen.

Update, August 13: the approval email arrived the next morning, both sensitive scopes, no questions. The full step-by-step playbook, from scope list to the three rules the approval email leaves you with, is in How We Passed Google OAuth Verification in a Day.

FAQ

Does the video need to show the sign-in flow?
If your app offers Google Sign-In on the same OAuth client, yes. The declared scope list is the union of every flow on the client, and each declared scope needs its moment on camera.

Why doesn't the consent screen appear for my test account?
First-grant only, under prompt=select_account. Use a Google account that has never granted to your app, or revoke the app from the account's Google connections page and try again.

Should the unverified-app warning appear in the video?
Yes. The form says it must be shown, and reviewers expect it. It disappears when verification completes.

How long does the review take?
Google's console told us 3 to 5 days to first contact and up to 4 to 6 weeks overall. Existing users keep working while it runs. Change nothing the reviewers are reading.