Google OAuth: homepage and privacy policy

What reviewers check

1. A recognizable public homepage

   Google checks that the homepage identifies the app, explains its function and links the consent screen’s privacy policy.

   Official source: Google: Homepage requirements

2. Accurate data disclosures

   Disclose how your app accesses, uses, stores and shares Google user data. Actual behavior must match.

   Official source: Google: Privacy disclosures

3. Justified sensitive scopes

   For sensitive-scope review, justify each scope and demonstrate the corresponding feature and authorization flow.

   Official source: Google: Sensitive-scope submission

Documented rejection risks

1. Missing domain ownership

   Unverified authorized domains fail a stated verification requirement. Check ownership before submission.

   Official source: Google: Domain ownership

2. Permissions beyond the feature

   Insufficient scope justification can cause rejection; Google may require narrower access. No frequency is implied.

   Official source: Google: Narrowest scopes

3. Undisclosed data use

   Hidden secondary uses can violate Google’s policy and put API access at risk. A generic policy does not fix mismatched behavior.

   Official source: Google: Prohibited deceptive use

Submission checklist

1. Check audience and exceptions

   Identify the project’s intended audience and publishing status before gathering review material. Compare the actual use case with Google’s listed exceptions, including development/testing and qualifying internal use. Record why an exception applies, if any. Do not equate a small customer count with an organization-owned Internal configuration or assume testing removes every limitation.

   Official source: Google: Verification exceptions

2. Put the full policy text on your domain

   Publish your privacy policy at a public HTTPS address on your app homepage’s domain, such as https://harbor.example/privacy.html. Put the full text in the page body: Google cannot process a policy that only appears inside an iframe or another embedded document. Keep the text readable without signing in. When your app starts to use a new tool or new data, update this page.

   Official source: Google: Policy page format and hosting

3. Publish matching pages

   Prepare a public homepage explaining the app and place the readable privacy policy on the same domain. Link that policy from the homepage and enter the matching address in the consent configuration. Compare the policy’s account of Google data handling against your implementation before asking Google to review it.

   Official source: Google: Privacy-policy links

4. Verify authorized domains

   List the registrable domains used by the app’s consent-screen URLs and OAuth credentials, including relevant redirect addresses and JavaScript origins. Configure the authorized domains and verify ownership through Search Console using an account associated with the Cloud project. For a subdomain, check the registrable parent domain rather than treating each URL path as a domain.

   Official source: Google: Authorized domains

5. Verify and publish branding

   In the selected Cloud project, open Branding and complete the app identity, contact information and page links. Run Verify Branding, inspect any reported problems and correct them. Once the result permits publication, use Publish branding. Then inspect Verification Center for any separate data-access requirements; an approved draft brand is not yet published branding.

   Official source: Google: Brand submission

6. Prepare the scope demonstration

   For each sensitive scope requiring review, explain the implemented feature and why narrower access would not work. Record an unlisted video showing the OAuth grant flow in English and the functionality enabled by each requested scope. Include the app name and client ID as required. The cited requirement does not say every feature’s interface must be English.

   Official source: Google: Sensitive-scope submission

7. Handle data-access review separately

   With branding published, use Verification Center to review the applicable data-access status. Declare the scopes actually requested, supply the requested justifications and demonstration, and monitor the project’s support and developer-contact inboxes. Respond to requests for clarification; publishing the homepage or policy does not complete sensitive or restricted-scope review.

   Official source: Google: Sensitive-scope submission

Example

1. Fictional app: Harbor Schedule

   Fictional input: Harbor Schedule only displays calendar entries the user chooses during an active session. Assume this example keeps the returned event details in memory and neither saves them in its database nor sends them to analytics. The owner lists each implemented API operation, compares available scopes and records the smallest scope that supports those operations. No exact scope is prescribed here. Expected artifact: a feature-to-operation-to-scope worksheet with a reason broader access is unnecessary. The in-memory and no-sharing statements must be verified in code before appearing in a real policy.

   Official source: Google: Minimum permissions

2. Fictional domain worksheet

   Fictional input: the owner controls harbor.example and prepares https://harbor.example/ as the homepage and https://harbor.example/privacy.html as the policy. The homepage explains the calendar display and links to that exact policy URL. The owner enters the same address in the consent configuration and checks both pages while signed out. Expected artifact: a submission worksheet showing matching URLs and a separate domain-ownership check. A policy hosted on another service does not establish ownership of harbor.example or replace the required same-domain publication.

   Official source: Google: Privacy policy requirements

3. Write only confirmed practices

   Fictional input: the owner has confirmed the example’s session-only handling of event details, but has not yet inspected error logs or OAuth-token storage. The draft describes the confirmed calendar-display purpose and marks those two unknowns for engineering review. The engineer checks whether either system persists Google user data, then updates the inventory and policy before submission. Expected artifact: a statement-by-statement evidence checklist, not an unconditional claim that nothing is stored. If real behavior differs from the fictional assumptions, both the disclosure and demonstration must reflect the real behavior.

   Official source: Google: Identity and intent

https://harbor.example/
https://harbor.example/privacy.html

Frequently asked questions

1. Is a privacy URL enough?

   No. Applicable sensitive-scope review also needs justification and a demonstration of the requested access.

   Official source: Google: Sensitive-scope submission

2. Can I submit a policy hosted on another service or in an iframe?

   Not as a shortcut. Google reads the policy text in the page body and cannot process a policy that only appears in an iframe. A URL on another service does not establish your domain ownership. Google documents some verified-owner and parent-organization alternatives, but none makes an unrelated hosting service your domain.

   Official source: Google: Privacy policy publication

3. Are internal apps exempt?

   Only qualifying organization-owned, internally configured apps meet the internal-use exception. A small audience alone is not that configuration.

   Official source: Google: Internal-only FAQ