Google OAuth Verification Kept Getting Rejected Until We Fixed These Issues

The application worked perfectly.

Google still rejected it.

We updated the documentation. Rejected again. We recorded a new demo video. Rejected again. Five rejections over eight weeks for an application that had zero bugs and handled user data correctly from day one.

Google OAuth verification is not a test of whether your application works. It is a test of whether you can prove that your application works, justify why it needs each scope it requests, demonstrate a complete user flow on video, and document your data practices in a way that satisfies a policy reviewer who will spend thirty minutes on your submission.

If you are building anything that touches Google Calendar, Gmail, Google Drive, Google Workspace, or Google Contacts, you will hit this process. Apps using sensitive or restricted scopes cannot go to production with real users until verification is complete. Your app stays locked in a warning-screen mode that scares away users and caps your audience at 100 test accounts.

This is the full account of what went wrong, what we fixed, and what finally got us through.

Our Environment

We were building a project management SaaS that connected to users' Google accounts for two features: syncing project deadlines with Google Calendar (creating, reading, and updating events) and attaching project documents stored in Google Drive to project records inside the app.

• Frontend: Next.js with a Google Sign-In button and an account connection flow in settings
• Backend: NestJS handling OAuth 2.0 token exchange, refresh token storage, and Google API calls
• Authentication: Google OAuth 2.0 using the authorization code flow with PKCE
• Google Calendar: reading upcoming events, creating deadline events, and updating event descriptions when task status changed
• Google Drive: reading file metadata for files the user selects, downloading files for preview inside the app
• Users: project managers and their teams at small-to-medium businesses

The scopes we needed put us squarely in the sensitive scope category. calendar.events for creating and updating calendar events. drive.file for accessing Drive files the user explicitly selects. These require Google verification. Without it, every user who tries to authorize the app sees a red warning screen that says the app is unverified. Most users click away immediately.

First Rejection: Insufficient Application Explanation

Twelve days after our first submission, the rejection arrived by email: 'The OAuth consent screen description does not adequately explain how your application uses Google user data. Please provide a clear explanation of how your application uses each requested scope.'

We read that and thought we had explained it. We had a one-line description on the consent screen and a paragraph in the submission form. Neither was specific enough for the reviewer to understand exactly what the app did with the Calendar and Drive data it was requesting.

Mistake #1: Writing a Generic Consent Screen Description

Google's reviewers need to understand your application's complete data flow from the consent screen description alone. They will not explore your app to figure it out. If the description is vague or generic, they have no basis for approving it.

What we originally wrote on the OAuth consent screen:

App name: Nurture Projects
Description: We use Google login and access your Google data to improve your productivity.

What we replaced it with:

App name: Nurture Projects
Description: Nurture Projects syncs your project deadlines to Google Calendar and lets you attach
Google Drive files to project tasks.

When you connect Google Calendar, Nurture Projects creates calendar events for task due dates,
reads your upcoming events to detect scheduling conflicts, and updates event descriptions when
task status changes. It never reads or modifies calendar events it did not create.

When you connect Google Drive, Nurture Projects reads the names, types, and preview thumbnails
of files you explicitly select. It does not access, read, or store Drive files without your
direct selection. No files are uploaded to or shared from your Drive on your behalf.

Your Google data is never sold or shared with third parties. You can disconnect your Google
account at any time from the Settings page, which revokes all access and deletes stored tokens.

Second Rejection: Demo Video Did Not Meet Requirements

We rewrote the description, resubmitted. New rejection: 'The provided demo video does not demonstrate how the application uses each requested scope. Please submit a video that shows the complete user flow including sign-in, permission grant, and the feature that uses the requested data.'

Our original video was two minutes long. It showed a user logging in and seeing a calendar view in the app. It did not show the OAuth permission dialog, did not show Google API data appearing in the UI, and did not demonstrate what happened to the data after it was loaded.

Mistake #2: Recording an Inadequate Demo Video

Google's review team relies on demo videos to verify that requested scopes are actually used for the stated purpose. A video that skips the permission dialog, shows placeholder data instead of real Google API responses, or fails to demonstrate a specific scope's feature will result in rejection.

The five-part structure that Google's reviewers expect:

1. 1Login: start from a logged-out state; show the Google Sign-In button; click it and show the redirect to accounts.google.com
2. 2Permission request: show the OAuth consent screen with the exact scopes your application is requesting; do not skip this screen; it is the most important part of the video
3. 3Feature demonstration: navigate to the specific feature powered by each scope; show real data loading from the Google API in your UI not mock data or empty states
4. 4Data usage: show how the data is displayed and used in the application; for Calendar, show an event being created and appearing in Google Calendar; for Drive, show a selected file's metadata appearing in the app
5. 5Account disconnect: navigate to settings and show the revoke/disconnect flow; confirm that after disconnect, the app no longer shows Google data

Additional video requirements Google looks for:

• Host on YouTube as an unlisted video this is the most reliable delivery format for Google reviewers
• Keep the video under 5 minutes total
• Record at a resolution where UI text is clearly readable without zooming
• Include audio narration or on-screen captions explaining what each step demonstrates
• Do not fast-forward through the permission dialog show the full consent screen visible for at least 3 seconds
• Demonstrate each scope separately if requesting multiple sensitive scopes
• Use a real Google account with actual data, not an empty account with no calendar events or Drive files

Third Rejection: Scope Requests Not Justified

Third submission, improved video, better description. New rejection: 'The requested scopes appear broader than necessary for the described use case. Please review your scope selection and request only the minimum scopes required for your application's features.'

We looked at our scope list and found the problem.

Mistake #3: Requesting Scopes Broader Than Necessary

When we first set up the OAuth flow, we had chosen scopes with a 'might as well get the broader one' logic. For Drive, we had requested the https://www.googleapis.com/auth/drive scope full Drive access. For Calendar, we had requested https://www.googleapis.com/auth/calendar full Calendar read and write access.

Our original scope request:

Scopes requested (submission v1):
  openid
  profile
  email
  https://www.googleapis.com/auth/calendar
  https://www.googleapis.com/auth/drive

Reviewer note: "auth/drive provides full access to all Google Drive files.
Your use case (attaching user-selected files) does not require full Drive access.
auth/drive.file is sufficient and limits access to files created by or opened
with your application only."

We replaced both with narrower scopes:

Scopes requested (submission v2):
  openid
  profile
  email
  https://www.googleapis.com/auth/calendar.events
      Creates and updates calendar events for task deadlines only.
      Does not read events created by other applications.
  https://www.googleapis.com/auth/drive.file
      Reads metadata and content of files the user explicitly selects
      via the Google Picker. Does not access any Drive file the user
      has not directly chosen.

Scopes intentionally NOT requested:
  auth/calendar   not needed; we only manage events we create
  auth/drive   not needed; drive.file covers all picker-selected file access

The scope change was not just about satisfying the reviewer. drive.file is genuinely a better choice. It limits the app's access to files the user explicitly opens via the Google Picker API, which is a tighter security boundary than full Drive access. Users who understand OAuth scopes will trust drive.file more than drive. The least-privilege scope is both more approvable and more trustworthy.

Fourth Rejection: Privacy Policy Issues

Narrower scopes, better video, clearer description. Fourth rejection: 'Your privacy policy does not clearly describe how Google user data is collected, used, and stored. Please ensure your privacy policy meets Google's requirements and is hosted at your authorized domain.'

Mistake #4: Privacy Policy Did Not Cover Google Data Specifically

We had a privacy policy. It covered standard data practices. What it did not cover was the specific Google user data calendar events, Drive file metadata that we were requesting, or the specific handling rules Google requires all OAuth apps to document.

Google's privacy policy requirements for OAuth applications:

• Hosted at the authorized domain listed in your OAuth consent screen (not a subdomain, not a third-party policy host)
• Directly accessible at a permanent URL no login required, no redirects to a PDF or paywall
• Explicitly names Google APIs accessed (e.g., Google Calendar API, Google Drive API)
• Describes what Google user data is collected and why (be specific: 'calendar event titles and dates' not 'calendar data')
• States that Google user data is not shared with third parties except as required to operate the service
• Includes the data retention period how long Google-sourced data is stored
• Includes user data deletion instructions: how a user can request deletion of all Google-sourced data
• Explicitly states that Google user data is not used for advertising, credit scoring, or any purpose not directly related to the app's stated function
• Complies with Google's Limited Use Policy for sensitive and restricted scopes: 'The app's use of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements'

Fifth Rejection: Reviewer Could Not Test the Application

Fixed the privacy policy, resubmitted. Fifth rejection: 'We were unable to test the application. Please provide test account credentials or instructions for accessing a demo environment.'

Mistake #5: No Test Accounts Provided

We had assumed the reviewer would use their own Google account to test the app. This assumption was wrong. Google reviewers may not be able to use personal accounts for testing production flows, and even if they could, they would encounter an empty app with no existing project data to demonstrate the Calendar and Drive integration meaningfully.

The correct approach is to add test user accounts in Google Cloud Console and provide dedicated login credentials:

• In Google Cloud Console, go to APIs & Services > OAuth consent screen > Test Users
• Add the email addresses that reviewers will use to test the app (you can use Gmail accounts you control, created specifically for review)
• Create two to three test Google accounts for review purposes, each connected to a Google Workspace or Gmail account
• Pre-populate each test account with realistic data: create 5 to 10 calendar events in the test account, upload 3 to 5 sample files to Google Drive
• Configure your app with a test project that has existing tasks and deadlines so the Calendar and Drive features have data to demonstrate
• Include the test account credentials (email and password) clearly at the top of your review submission notes
• Confirm the test account can complete the full OAuth flow and access all demonstrated features before submitting

Sensitive Scopes vs Restricted Scopes

Understanding the difference between scope categories determines your verification strategy. Getting this wrong means either requesting a scope that requires a security audit when a less powerful scope would have sufficed, or requesting too narrow a scope and having to resubmit when the feature needs more access.

SCOPE CATEGORY COMPARISON
=========================

Category     Risk    Verification      Examples                  Requirements
-----------  ------  ----------------  ------------------------  ---------------------------
Non-sens.    Low     None              openid, profile, email    None   available to all apps
Sensitive    Medium  Form + video      calendar.events,          1-4 week review
                                       drive.file,               Demo video required
                                       contacts.readonly         Privacy policy required
Restricted   High    CASA Tier 2 +     gmail.*,                  Security audit ($3K-$5K)
                     security audit    drive (full),             4-8 week review
                                       admin.directory           Annual reassessment

COMMON SCOPE DECISIONS
======================

Feature               Wrong Scope        Right Scope         Reason
--------------------  -----------------  ------------------  ---------------------------------
Read user's calendar  auth/calendar      calendar.readonly   Read-only if no writes needed
Create events only    auth/calendar      calendar.events     Narrower than full calendar
Access one file       auth/drive         drive.file          Only files opened by your app
Gmail search          auth/gmail         gmail.readonly      Read-only if not sending
Email send only       auth/gmail         gmail.send          Narrower than full Gmail access

The key insight from that table: most common use cases that initially reach for a broad scope can be served by a narrower one. Full drive access is almost never necessary for SaaS integrations. drive.file covers picker-based access. drive.readonly covers read-only browsing. Full gmail access is almost never necessary gmail.send, gmail.readonly, or gmail.compose cover the vast majority of Gmail use cases without requiring the restricted scope security audit.

Requesting a restricted scope when a sensitive scope would suffice forces you into a CASA (Cloud Application Security Assessment) Tier 2 security audit. This is a third-party security review that costs several thousand dollars and adds four to eight weeks to your timeline. Avoiding restricted scopes through careful scope selection is not just faster it is significantly cheaper.

What Finally Got Approved

• Google Sign-In (openid, profile, email): approved on submission 4 alongside privacy policy fix
• calendar.events: approved on submission 5 alongside test accounts
• drive.file: approved on submission 5 alongside test accounts

Total elapsed time from first submission to approval: eight weeks. Four weeks was resubmission preparation time on our side. Four weeks was Google review queue time across submissions. Google's review queue depth varies considerably. Standard reviews typically take one to four weeks. If a reviewer cannot reach a decision and escalates to a policy specialist, add another one to three weeks.

The practical timeline recommendation for any team building a Google integration: submit your first verification request six to ten weeks before your intended launch date. Do not plan a hard launch date that depends on Google verification completing by a specific day.

Google Verification Checklist

Consent Screen

• App name matches the name displayed to users in the product
• User support email is a monitored address, not a noreply alias
• App logo is uploaded and meets Google's requirements (512x512px, no Google branding)
• App homepage URL is a live, publicly accessible page describing the product
• Privacy policy URL points to a live page on your authorized domain
• Terms of service URL points to a live page on your authorized domain
• Authorized domains include your production domain
• Developer contact email is monitored Google may contact you here during review
• Consent screen description explains each scope's purpose specifically

Privacy Policy

• Hosted at the exact authorized domain listed in the OAuth consent screen
• Publicly accessible without login or redirect
• Explicitly names each Google API your app accesses
• Describes what specific Google user data is collected (not generic 'Google data')
• States the purpose for collecting each type of Google data
• Includes data retention period for Google-sourced data
• Includes user data deletion instructions
• States that Google user data is not shared with third parties except as required to operate the service
• Includes Google's Limited Use Policy compliance statement verbatim
• Does not use Google user data for advertising, credit scoring, or non-app purposes

Terms of Service

• Publicly accessible at your authorized domain
• References acceptable use for Google-connected features
• Does not contradict Google's API Terms of Service
• Covers account termination and data deletion procedures

Verification Video

• Hosted on YouTube as unlisted
• Under 5 minutes in total length
• Starts from a fresh logged-out state
• Shows the Google Sign-In button and the click to authorize
• Shows the full OAuth consent screen with all requested scopes visible
• Demonstrates each scope's feature with real API data visible in the UI
• Includes audio narration or on-screen captions
• Shows the account disconnection / revoke access flow at the end
• Resolution is high enough to read UI labels clearly

Test Accounts

• Test Google accounts added as Test Users in OAuth consent screen settings
• Test accounts pre-populated with realistic Calendar events and Drive files
• Test account credentials included in the review submission notes
• Test accounts can complete the full authorization flow and access all demonstrated features
• Test passwords are strong and shared only in the submission, not in public documentation

Scope Justification

• Each requested scope is the narrowest scope that supports the required feature
• Each scope has a one-to-two sentence justification in the submission form
• Each scope is demonstrated in the video
• No scopes are requested for future features submit a new verification when those features are built
• drive.file is used instead of drive whenever possible
• gmail.send or gmail.readonly is used instead of gmail whenever possible
• calendar.events is used instead of calendar when only event management is needed

Security

• OAuth tokens are stored encrypted at rest
• Refresh tokens are stored in the database, not in browser storage
• Access tokens are never logged in plaintext
• Token revocation is implemented and tested
• HTTPS is enforced on all redirect URIs
• PKCE (Proof Key for Code Exchange) is implemented for the authorization code flow

Brand Verification

• App homepage describes the product clearly
• Privacy policy domain matches the authorized domain
• App name does not imply affiliation with Google
• App logo does not include Google's branding elements
• App is in production or has a clear path to production (not a test project)

Google Login Verification Checklist

Google Sign-In using only the non-sensitive scopes (openid, profile, email) does not require verification for production use. Your app can go live immediately. However, you still need a properly configured consent screen, an accessible privacy policy, and compliant data handling. Common issues that still cause problems in unverified sign-in flows:

• Unverified app warning appears because the consent screen app type is set to External and the app is not verified users see a red warning screen; add test users or complete verification to remove it
• The authorized redirect URI in Google Cloud Console does not exactly match the redirect URI in your code causes redirect_uri_mismatch errors
• Privacy policy URL is not accessible causes the consent screen to show a broken link
• App logo is missing or rejected causes the consent screen to show a generic app icon which reduces user trust
• The app requests profile and email but the privacy policy does not mention what the app does with the user's name and email address

Google Calendar API Verification Checklist

Calendar API permissions are sensitive scopes. Verification is required before production use with external users. The review focuses on whether calendar data is used strictly for the stated scheduling or productivity purpose.

• Requested scope is the narrowest that covers the use case: calendar.readonly for reading, calendar.events for create/update, calendar for full access
• The demo video shows a specific calendar feature: an event being created, a calendar view rendered, or a scheduling conflict being detected
• Real calendar data from the test account is visible in the UI during the video (not an empty calendar)
• Privacy policy explains that calendar data (event titles, times, descriptions) is used only to power the scheduling feature and is not stored beyond the app's operational needs
• The consent screen description explains which calendar actions the app takes on behalf of the user
• The app correctly handles the case where a user has no calendar events the UI shows an empty state rather than an error
• Revocation is tested: after a user disconnects Google Calendar, the app no longer accesses calendar data and removes stored calendar tokens

Google Drive API Verification Checklist

Drive API scope selection is critical. drive (full access) is a restricted scope and requires a CASA Tier 2 security audit. drive.file and drive.readonly are sensitive scopes and only require standard verification. Most SaaS use cases can be served with drive.file.

• Use drive.file instead of drive whenever the app only accesses files the user explicitly selects via Google Picker
• Use drive.readonly instead of drive when the app needs to browse and read Drive files but never creates or modifies them
• The demo video shows the Google Picker opening, a file being selected, and file data appearing in the app UI
• Real Drive files exist in the test account for the reviewer to select during testing
• Privacy policy explains that Drive file metadata and content are accessed only for files explicitly selected by the user
• Privacy policy states that files are not uploaded to Drive, shared, or transferred to third parties
• File content is not stored server-side beyond the immediate operation (unless the use case explicitly requires storage, which must be documented)
• The app handles the case where a user selects a file they do not have permission to view the error state is graceful and informative
• Token revocation removes all Drive access and any stored file content associated with the user's account

Lessons Learned

1. 1Google OAuth verification is a documentation problem, not a code problem your application's correctness is assumed; the review is about proving your data practices
2. 2Write the consent screen description for a policy reviewer who does not know your product and needs to understand the full data flow in two paragraphs
3. 3The demo video must show the OAuth consent screen dialog, not skip past it it is the centerpiece of the verification, not an administrative step
4. 4Show real Google API data in the demo video mock data or empty states give the reviewer nothing to verify
5. 5Host the demo video on YouTube as unlisted; avoid sharing as a file download or from a hosting service that requires login
6. 6Always choose the narrowest scope that covers your use case drive.file over drive, calendar.events over calendar, gmail.readonly over gmail
7. 7Restricted scopes (full Gmail, full Drive) trigger a CASA security audit; avoiding them through careful scope selection saves weeks and thousands of dollars
8. 8Your privacy policy must include Google's Limited Use Policy compliance statement verbatim a paraphrase is not accepted
9. 9The privacy policy must be hosted at the authorized domain in your consent screen settings a third-party policy host does not satisfy this requirement
10. 10Provide dedicated test accounts pre-populated with realistic data reviewers cannot test a scheduling feature on an empty calendar
11. 11Add test accounts as Test Users in Google Cloud Console before submitting this step is required for the reviewer's account to authorize your app without seeing the unverified warning
12. 12Never request permissions for features you have not built and demonstrated submit a separate verification request when those features are ready
13. 13Budget six to ten weeks for verification before your launch date do not plan a hard launch that depends on Google approving by a specific deadline
14. 14If your submission is rejected, read the rejection message carefully and fix every item on the checklist before resubmitting, not just the specific item mentioned
15. 15The Google API verification portal allows you to provide a note to the reviewer; use this to pre-answer likely questions about your scope justifications and data handling

Approval Framework

After five rejections, we built a systematic preparation process. Every Google OAuth submission we make now goes through these seven stages before the Submit button is clicked:

flowchart TD
  A["Document\nPrivacy policy, ToS,\nGoogle Limited Use statement"] --> B["Explain\nConsent screen description\nper-scope justification"]
  B --> C["Record\nYouTube demo video\nall scopes demonstrated"]
  C --> D["Verify\nAll checklist items\nchecked internally"]
  D --> E["Test\nTest accounts populated\ndry run with reviewer credentials"]
  E --> F["Submit\nAll fields complete\nnotes to reviewer added"]
  F --> G["Approve\n✓ Verification complete"]

• Document: write or update the privacy policy to explicitly cover each Google API and scope, including the Limited Use Policy compliance statement
• Explain: write the consent screen description for a non-technical policy reviewer; write one-sentence justifications for each scope in the submission notes
• Record: make the YouTube demo starting from logged-out, showing every scope's feature with real data, ending with account disconnection
• Verify: run through every checklist category; treat any unchecked item as a guaranteed rejection reason
• Test: follow your own instructions using only the test account credentials you are about to provide; if you cannot complete the flow, the reviewer cannot either
• Submit: fill every required field, attach the video URL, add notes to the reviewer explaining the use case context
• Approve: once approved, document the approved scopes and the specific version of documentation that passed this becomes the baseline for future scope additions

Conclusion

Most Google OAuth verification failures are not caused by code. The application handles tokens correctly. The API calls work. The user flow is clean. The failures come from documentation, scope selection, video quality, privacy policy compliance gaps, and not giving reviewers the tools they need to test the application independently.

Google's review process is genuinely trying to determine whether your application handles user data responsibly, uses the minimum permissions it needs, and can be trusted with access to sensitive data like calendar events and Drive files. Reviewers who cannot verify this will not approve it.

The fix is systematic preparation. Treat the verification submission as a product in its own right one where the user is the reviewer and the job-to-be-done is verification in under thirty minutes. Make it impossible to fail by giving the reviewer everything they need, documented clearly, demonstrated completely, and tested thoroughly before you submit.

Need help implementing secure Google OAuth flows, preparing verification submissions, or building production-ready Google Calendar, Drive, Gmail, or Workspace integrations? Nurture Technologies designs and implements Google integrations from architecture through verification, including scope strategy, privacy policy compliance, demo video preparation, and production deployment. Talk to us about your Google integration.