Skip to content
← All posts
App review · 6 min read ·

The Google OAuth verification video: what reviewers need to see

Google asked for a demo video of your OAuth flow. Here is what it has to show, a scene-by-scene recording plan, and how to cut it down without losing the consent screen.

Sansavision team
Makers of DemoTake ·

Your app asks for access to Google data, and the verification team wants a video. The request is short, the stakes are not: if the video doesn't clearly show what they are looking for, you get another round of emails and another week of waiting.

This post covers what an OAuth verification video generally needs to show, how to plan the recording so nothing is missing, how long to leave the consent screen up, and how to shorten the video without cutting the parts reviewers check. Then we show how DemoTake's reviewer workflow helps.

Note:

Google's requirements change over time. Before you record, read Google's current help page on OAuth app verification and the exact wording of the request you received. This post describes the widely known basics, not an official checklist.

What Google's reviewers need to see

In broad terms, a verification video shows that the app you submitted really asks for the access you declared, and really uses it the way you described. That usually comes down to:

  • The OAuth consent screen, readable. The screen where the user grants access, showing your app's name as configured in your project and the permissions being requested.
  • The same OAuth client you submitted. The sign-in URL contains your OAuth client ID, so keep the browser's address bar visible during sign-in. It lets the reviewer match the video to your project.
  • Every sensitive or restricted scope in use. For each scope you request, show the feature that needs it, working, with the data it reads or writes.
  • A link reviewers can open. The video is usually shared as an unlisted link, so it isn't public but anyone with the link can watch.

If your request email lists specific items, treat that list as the real checklist and make sure each item appears clearly on screen.

Plan the recording scene by scene

Write the plan before you record. One scene per thing the reviewer must see makes it easy to check coverage and to retake a single part if something goes wrong.

Google OAuth review5 scenes
  1. 1Open the app and start sign-in✓ Google sign-in page with the address bar visiblePending
  2. 2Consent screen✓ App name and requested access readablePending
  3. 3Signed in✓ The app shows the connected accountPending
  4. 4Scope 1: read calendar events✓ Upcoming events listed in the appPending
  5. 5Scope 2: create an event✓ The new event appears in the calendarPending
A recording plan for an app that asks for two calendar scopes. Each scene ends on the screen a reviewer needs to see.

For each scope, write down what proves it's used:

Scope (example) Show this End the scene on
Read calendar events The app loading your upcoming events The list of events in the app
Create events Creating an event in the app The same event visible in the calendar
Read email metadata The feature that uses it, such as a sender summary The summary with recognizable test data

Use a test Google account with realistic but fake data. Reviewers need to see the data flowing, not your real inbox. If anything personal does show up, blur it: see How to blur emails, API keys and card numbers.

This is where most videos go wrong. Whoever records has clicked through it a hundred times and does it in half a second. The reviewer needs to read the app name and each permission.

  • Stop on the consent screen and don't move for several seconds.
  • Allow a couple of seconds to find the heading, then time to read each permission line.
  • If the list of permissions is long or needs scrolling, scroll slowly and pause again.
  • Keep the pointer still or point at each permission as you go. Don't wave it over the text.
  • Only then grant access.

Raw verification recordings are long: sign-in pages load, syncs run, you wait for data to appear. Shortening those waits is fine and makes the video easier to review. Cutting the consent screen, or cutting across the moment a result appears, is not. It makes a video look edited in exactly the places a reviewer cares about.

A real example: a Google OAuth review recording made with DemoTake went from 8:02 to 3:58 with 31 suggested cuts, without losing a single consent screen. The waits were shortened to their first seconds, and the consent screens kept their reading time. The full walkthrough is in How to remove dead air from a screen recording.

Raw
LoadingConsentSyncResult
Edited
ConsentResult
ActionSuggested cutProtectedKept: reading time
8:02 → 3:58 · 31 cuts · 0 consent screens lost
Waits get shortened. The consent screen and the results keep their time.

How DemoTake helps with a verification video

A take with the Reviewer purpose

Choose File › New Reviewer Pack… (⇧⌘N), or pick Reviewer as the purpose in New Take. A reviewer take is conservative on purpose: no zooms, a calm pointer with a highlight ring, no background or padding around the window, and captions on.

Plan the scenes as above and record them one by one, ending each with Create Checkpoint (⌘D). If the consent scene goes wrong, retake only that scene. The others keep their footage.

When you run Find Pauses in the editor's Review tab, DemoTake recognizes consent screens by their wording (phrases such as "wants access" and "will be able to") and keeps 6 to 8 seconds of each, depending on how much text is on it. Consent and result screens are flagged for you to look at before accepting, and nothing is ever cut across an assertion, a checkpoint or a result. See Footage review.

The Reviewer Pack and proof manifest

Export a Reviewer Pack and you get a ZIP with three files:

  • the video, rendered with the conservative reviewer style;
  • reviewer-notes.md: your notes, the steps (one per scene), the checks that passed, and the editing disclosures;
  • manifest.json: what was recorded and on what: the flow, app and macOS versions, each assertion with its time, the source commit when known, a SHA-256 hash of the video, and an honest list of the edits applied.
manifest.json (excerpt, values illustrative)
{
  "flow": "Sign in with Google and use calendar access",
  "assertionsPassed": 2,
  "assertionsTotal": 2,
  "editDisclosures": [
    "Waits over 1.0 s shortened to 0.4 s (still visible).",
    "31 range(s) sped up.",
    "31 unchanged screen(s) shortened; each keeps its start and the moment before the screen changes.",
    "Pointer is a presentation layer synthesized from recorded actions."
  ],
  "videoFile": "google-oauth-review-reviewer.mp4",
  "videoSHA256": "9f2c…e41a"
}

Google's form asks for a video link, so upload the MP4 from the pack as an unlisted video. Keep the notes and manifest for your own records, or for any reviewer who asks how the video was edited. In Reviewer Mode you can add checks such as Visible Text ("Upcoming events"), use Copy Reviewer Notes to paste them into a form, and use Share Link… to send the take to a colleague for a second look. More in Reviewer Packs.

Tip:

During the free trial, exports carry a "Made with DemoTake" watermark. Use a licensed export for the video you submit.

A checklist before you submit

  • Every scope in your submission has a scene that shows it in use.
  • The consent screen is readable, with your app's name and the requested access.
  • The address bar is visible during sign-in.
  • Test account, test data, nothing personal on screen.
  • Waits shortened, consent screen and results untouched.
  • Watched once at full speed by someone who didn't record it.
  • Uploaded as unlisted, and the link opens in a private browser window.

When your next verification request arrives, download DemoTake and start with File › New Reviewer Pack….