Google OAuth verification: privacy policy and release checklist

A privacy policy is one part of Google OAuth review. It does not guarantee approval.

The required review depends on app type, publication status, requested scopes, branding, user count, and data use. Non-sensitive scopes can follow a different path from sensitive or restricted scopes. Check Google’s current requirements before each submission.

1. Classify the app and scopes

Inventory every requested scope and the feature that needs it. Remove scopes that are unused, broader than necessary, or requested only for a future feature.

Google’s OAuth verification requirements distinguish brand verification, sensitive-scope verification, and restricted-scope verification. Restricted scopes can introduce an independent security assessment and recurring obligations.

Do not describe a scope as “login only” if the app reads Drive, Gmail, Calendar, health, or other data after authentication.

2. Prepare the public app identity

The app homepage should be:

• on a domain you control and verify;
• public without authentication;
• clearly associated with the app name shown on the consent screen;
• descriptive of the app’s purpose and user-facing features; and
• linked to the privacy policy and, where relevant, terms.

Google’s app-homepage guidance explains the presentation and domain expectations. Keep logo, name, support contact, authorised domains, homepage, and privacy-policy URL consistent across the Cloud project and website.

3. Write a policy for the real Google data flow

The policy should explain:

• which Google user data is obtained;
• why each category is used;
• how it is processed and shared;
• whether humans can access it and under what conditions;
• how long it is retained;
• how a user can revoke access and request deletion;
• security and transfer information where relevant; and
• the controller’s identity and contact route.

Avoid saying only “we use Google for login” if broader scopes are requested. Avoid copying the scope names without explaining the product purpose.

Also review Google’s OAuth 2.0 policies and Limited Use requirements where applicable. The disclosure must match the deployed app and its provider configuration.

4. Make the implementation match

Before submitting:

1. verify domain ownership;
2. publish the exact homepage and policy URLs entered in the console;
3. confirm production redirect URIs and JavaScript origins;
4. request the minimum scopes at the point they are needed;
5. test revocation and deletion;
6. restrict credentials and protect client secrets;
7. prepare test accounts that reach the reviewed flow; and
8. record what Google data enters logs, support tools, analytics, AI providers, and backups.

If a feature requests incremental authorisation, capture that journey too.

5. Prepare the evidence

Google may ask for a video or written explanation showing the OAuth flow and how each scope is used. The submission guidance lists current preparation steps.

Make the evidence reproducible:

• start from the public homepage;
• show the consent screen;
• reach every scope-dependent feature;
• narrate which API call supports which feature;
• avoid exposing real user data or credentials; and
• ensure the review account has the correct permissions and stable data.

Respond to the precise reviewer question. If code or configuration changes, update the recording and policy before resubmitting.

What GDPR.Direct can do

GDPR.Direct can generate and host an editable privacy-policy draft on a public URL. You must provide the real scopes, data uses, recipients, retention, and deletion process. The product does not verify domain ownership, inspect Google API calls, configure the consent screen, prepare a security assessment, or guarantee Google approval.

Google can change its programme. Re-check the linked official pages on the day of submission.

This guide is educational information, not legal advice or an endorsement by Google.