# Google (Gmail, Drive, Calendar): OAuth app setup guide

> Curated guide, updated 2026-10-30. Source: https://oauthseus.vercel.app/guides/google

**Difficulty:** hard. Under an hour to test with 100 users; ~2-6 weeks for sensitive scopes; 6-12+ weeks plus a paid yearly CASA audit for Gmail read or full Drive _[documented s10,s5,s6]_

Creating a Google Cloud project, configuring the Google Auth Platform and minting an OAuth client takes under an hour, and in Testing mode you can connect up to 100 named test users immediately (but their refresh tokens die after 7 days). Going public is where it gets hard: sensitive scopes (Calendar, gmail.send) need brand + scope verification with a demo video (Google estimates ~10 business days), and restricted scopes (reading Gmail, full Drive) additionally need an annual paid CASA security assessment from an authorized lab (Google estimates ~6 weeks; community reports 3-12 weeks). The single biggest lever is scope choice: drive.file instead of drive, gmail.send instead of mail.google.com.

**Your work:** 1–3 days. **Waiting on provider:** 2–6 weeks (review depends on path).

Default path assumed: a public agent using sensitive scopes (e.g. Calendar, gmail.send, drive.file). No approval is needed for Testing (<=100 test users) or Internal (Workspace org only) apps. Publishing an External app triggers brand verification (automated, usually minutes) and, for sensitive/restricted scopes, a data-access review by Google's OAuth / Trust & Safety team via the Verification Center. Restricted scopes add a CASA security assessment by an App Defense Alliance authorized lab. Google's own estimate for sensitive scopes is 10 business days; the 2-6 week range includes typical back-and-forth reported by developers.

## Launch paths

| Path | Difficulty | Your work | Provider wait |
|---|---|---|---|
| External app in Testing (you + up to 100 test users) | easy | 30–60 min | None |
| Internal app (single Google Workspace / Cloud Identity org) | easy | 30–90 min | None |
| Public app, non-sensitive scopes only (sign-in, drive.file, gmail.labels) | moderate | 2–4 hours | 0–3 days |
| Public app, sensitive scopes (Calendar, gmail.send, contacts) | hard | 1–3 days | 2–6 weeks |
| Public app, restricted scopes (read Gmail, full Drive) | hard | 1–4 weeks | 3–12 weeks |

## Do these first

1. Decide your scope list now: can you use drive.file and gmail.send instead of restricted Gmail/Drive scopes?
2. Create separate dev and prod Cloud projects; in dev, configure External + Testing and add yourself as a test user
3. Create a Web application client (tick 'Use this client for an AI-powered agent'), register redirect URIs, and store the secret immediately
4. Publish homepage + privacy policy with a Limited Use statement on your domain and verify it in Search Console
5. If you need restricted scopes, budget 6-12 weeks and an annual CASA lab fee before launch

## What you're registering

**OAuth client in a Google Cloud project (configured under Google Auth Platform).** One Google Cloud project holds one 'app' identity (branding, audience, data access scopes, verification status) and one or more OAuth clients (client ID + secret per platform: Web application, Desktop, iOS, Android, etc.). Your product typically uses one Web application client; each end user who connects authorizes that client and yields their own refresh token. Verification and the 100-user cap are per project, so Google recommends separate projects for dev/test and production. Google now offers a 'Use this client for an AI-powered agent' flag and asks you to keep separate client IDs for human-interactive and agent workflows; some Google MCP endpoints (e.g. Workspace tools) only accept agent-tagged clients.

Request access_type=offline to get a refresh token (prompt=consent forces re-issue). Access tokens are short-lived; refresh tokens stop working if: user revokes, unused for 6 months, user changes password and token has Gmail scopes, per-account token limit exceeded (100 refresh tokens per Google Account per client: the oldest is silently invalidated), time-based access expired, or a Workspace admin restricts the service (admin_policy_enforced). External apps in Testing get refresh tokens that expire after 7 days unless only openid/email/profile are requested. OAuth clients unused for six months are automatically deleted (30-day email warning). Client secrets are shown only once at creation.

## What you'll need

- **Google account + Google Cloud project**: Any Google account can create a project; no billing is required for Gmail/Drive/Calendar APIs. Use separate projects for development/testing and production. _[documented s8]_
- **Google Workspace / Cloud Identity organization owning the project**: Required only for the Internal user type; the project must sit under the org (check IAM & Admin > Settings > Location). _[documented s2]_
- **Homepage, privacy policy and terms of service on a domain you own**: Homepage must describe the app (not just a login page) and link the privacy policy; privacy policy must be on the same domain, match the consent-screen link, and disclose how Google user data is accessed, used, stored and shared, including Limited Use compliance. _[documented s3]_
- **Verified domain ownership (Google Search Console)**: Every Authorized Domain must be verified in Google Search Console by an account that is an Owner or Editor on the Cloud project. _[documented s4]_
- **App logo (optional but triggers verification)**: Square 120x120 px, <=1 MB, JPG/PNG/BMP. Name and logo appear on the consent screen only after brand verification. _[documented s3]_
- **Scope justification**: Per sensitive/restricted scope, explain the user-facing feature and why a narrower scope would not work. Requesting scopes for future features is grounds for rejection. _[documented s4]_
- **Demo video**: Unlisted YouTube video showing the end-to-end flow, the complete OAuth consent screen (English, exact scopes requested) and each scope's use in the app. If data is used for personalized AI model training, it must show the user explicitly consenting. _[documented s4]_
- **Limited Use compliance (incl. AI training restrictions)**: Google user data may only power user-facing features; no ads, no data brokers, no credit decisions, no humans reading data without consent, and no training/improving foundation or frontier models. Add a Limited Use disclosure sentence to your site. _[documented s10]_
- **CASA security assessment (annual, paid to lab)**: App Defense Alliance Cloud Application Security Assessment based on OWASP ASVS, performed by an authorized lab at the assurance level Google assigns (AL1 or AL2). Google charges nothing; the lab fee is negotiated directly. Applies when restricted data is accessed from or through your servers. Critical/high findings must be remediated to get the Letter of Validation/Assessment. _[documented s10,s12]_
- **Up-to-date project contacts**: All verification communication goes by email to project owners/editors and the developer contact emails; missed emails can cost API access. _[documented s4]_

## Steps

### 1. Create a Google Cloud project (2–5 min, you)

1. Open the New Project page in the Google Cloud console.
2. Enter a Project name (e.g. 'myagent-prod'; create a second 'myagent-dev' project for testing).
3. If you have a Workspace org and want an Internal app, set Location to your organization.
4. Click Create and wait for the notification, then make sure the new project is selected in the project picker.

[Creating and managing projects](https://cloud.google.com/resource-manager/docs/creating-managing-projects) · [Submitting your app for verification (project setup)](https://support.google.com/cloud/answer/13461325) _[documented s8]_

### 2. Enable the Gmail, Google Drive and Google Calendar APIs (2–5 min, agent prepares, you submit)

1. Open APIs & Services > Library.
2. Search for 'Gmail API', open it and click Enable.
3. Repeat for 'Google Drive API' and 'Google Calendar API' (only the ones you need).
4. Read each API's scope page now so you can pick the narrowest scopes later.

[API Library](https://console.cloud.google.com/apis/library) · [Submitting your app for verification (enable APIs)](https://support.google.com/cloud/answer/13461325) _[documented s8]_

### 3. Register the app in Google Auth Platform (formerly 'OAuth consent screen') (5–10 min, you)

1. Open Google Auth Platform > Overview. If the app is not configured yet, click Get started.
2. App Information: enter App name (must not contain or imitate 'Google', 'Gmail', etc.) and pick a User support email (your account or a Google Group you manage).
3. Audience: choose Internal (Workspace org members only, no verification) or External (any Google account; starts in Testing).
4. Contact Information: enter developer email address(es) that Google will use for verification and policy notices.
5. Finish: tick the agreement to the Google API Services: User Data Policy, then click Continue and Create.

[Google Auth Platform overview](https://console.cloud.google.com/auth/overview) · [Manage OAuth App Branding](https://support.google.com/cloud/answer/15549049) · [Manage App Audience](https://support.google.com/cloud/answer/15549945) _[documented s9,s3]_

### 4. Fill in Branding: links, logo and Authorized domains (30–180 min, agent prepares, you submit)

1. Open Google Auth Platform > Branding.
2. Under Authorized domains, click Add domain and enter your top private domain (e.g. example.com) BEFORE adding any URLs that use it.
3. Under App domain, enter Application home page, Application privacy policy link and Application terms of service link (all on the authorized domain; homepage must link to the privacy policy).
4. Optionally upload an App logo (120x120 px square, <=1 MB). Note any logo change on a production app triggers re-verification.
5. Check Developer contact information and click Save.
   - Authorized domains: `example.com` (Top private domain only; subdomains are then allowed.)
   - Application privacy policy link: `https://example.com/privacy` (Same URL as the one linked from your homepage.)
   - Limited Use disclosure (on site): `{App}'s use of information received from Google APIs will adhere to Google API Services User Data Policy, including the Limited Use requirements.` (Sample wording provided in Google's FAQ.)

[Branding page](https://console.cloud.google.com/auth/branding) · [Manage OAuth App Branding](https://support.google.com/cloud/answer/15549049) · [Verification requirements](https://support.google.com/cloud/answer/13464321) _[documented s3]_

### 5. Declare scopes on the Data Access page (pick the narrowest) (10–30 min, agent prepares, you submit)

1. Open Google Auth Platform > Data Access and click Add or remove scopes.
2. Filter/select or paste scopes under 'Manually add scopes', click Add to table, then Update and Save.
3. The console groups them into 'Your non-sensitive scopes', 'Your sensitive scopes' and 'Your restricted scopes' - this grouping decides your verification path.
4. Prefer: drive.file (+ Google Picker) over drive/drive.readonly; gmail.send (sensitive) over mail.google.com for sending; gmail.labels where possible. Calendar scopes are not on the restricted list (sensitive). Only request Gmail read/modify scopes if the agent truly must read mail.
   - Non-sensitive Drive: `https://www.googleapis.com/auth/drive.file`
   - Sensitive Gmail send: `https://www.googleapis.com/auth/gmail.send`
   - Sensitive Calendar events: `https://www.googleapis.com/auth/calendar.events` (Classification inferred: Calendar scopes are absent from Google's restricted list.)
   - Restricted Gmail read: `https://www.googleapis.com/auth/gmail.readonly` (Triggers CASA if data reaches your servers.)

[Data Access page](https://console.cloud.google.com/auth/scopes) · [Restricted scopes list](https://support.google.com/cloud/answer/13464325) · [Choose Gmail API scopes](https://developers.google.com/workspace/gmail/api/auth/scopes) · [Choose Drive API scopes](https://developers.google.com/workspace/drive/api/guides/api-specific-auth) · [Choose Calendar API scopes](https://developers.google.com/workspace/calendar/api/auth) _[documented s8,s14]_

### 6. Add test users (External apps in Testing) (2–10 min, you)

1. Open Google Auth Platform > Audience.
2. Confirm Publishing status shows Testing.
3. Under Test users click Add users, paste Google account emails (max 100 for the project's lifetime of test-user slots), and click Save.
4. Warn testers they will see a 'Google hasn't verified this app' warning and must reconnect every 7 days.

[Audience page](https://console.cloud.google.com/auth/audience) · [Manage App Audience](https://support.google.com/cloud/answer/15549945) _[documented s2]_

### 7. Create the OAuth client (Web application) and register redirect URIs (5–10 min, you)

1. Open Google Auth Platform > Clients and click Create client.
2. Application type: Web application (server-side agent backend). Give it a Name.
3. If this client is used by your AI agent (tool calls, MCP), tick 'Use this client for an AI-powered agent'; create a separate standard client for any human-facing web UI.
4. Under Authorized redirect URIs click Add URI and paste each callback exactly (scheme, host, port, path). HTTPS required except localhost; no wildcards, fragments, raw IPs or path traversal.
5. Click Create, then immediately copy/download the Client secret - it will never be shown again (only its last 4 characters).
6. Allow 5 minutes to a few hours for redirect URI changes to propagate before debugging redirect_uri_mismatch.
   - Application type: `Web application`
   - Authorized redirect URIs: `https://app.example.com/oauth/google/callback` (Production callback; must match the redirect_uri parameter byte-for-byte.)
   - Authorized redirect URIs (dev): `http://localhost:3000/oauth/google/callback` (Plain HTTP allowed only for localhost; better in the separate dev project.)

[Clients page](https://console.cloud.google.com/auth/clients) · [Manage OAuth Clients](https://support.google.com/cloud/answer/15549257) · [OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server) _[documented s9]_

### 8. Implement the authorization-code flow and token storage (1–4 hours, agent can do)

1. Redirect users to https://accounts.google.com/o/oauth2/v2/auth with client_id, redirect_uri, response_type=code, scope, access_type=offline, include_granted_scopes=true, state (and PKCE).
2. Exchange the code at https://oauth2.googleapis.com/token; store the refresh token encrypted per user.
3. Check the granted scopes in the token response - users can uncheck individual scopes; disable features whose scopes were not granted.
4. Request scopes incrementally at the moment a feature needs them.
5. Handle invalid_grant (revoked, 7-day Testing expiry, 6-month inactivity, password change with Gmail scopes, 100-token-per-client limit) by prompting re-connection.

[Using OAuth 2.0 to Access Google APIs](https://developers.google.com/identity/protocols/oauth2) · [OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server) _[documented s1]_

### 9. (Internal / Workspace customers) Have a Workspace admin trust the app (5–15 min, you)

1. In the Google Admin console go to Security > Access and data control > API controls.
2. Click Manage Third-Party App Access, then Configure new app and search by your OAuth client ID.
3. Set access to Trusted (needed for restricted Gmail/Drive scopes if the org restricts those services; otherwise users get admin_policy_enforced).
4. For customer orgs using your public app, send their admin the client ID and these steps.

[Control which third-party & internal apps access Google Workspace data](https://support.google.com/a/answer/7281227) · [Manage App Audience (Internal)](https://support.google.com/cloud/answer/15549945) _[documented s2]_

### 10. Verify your domain in Google Search Console (10–60 min, agent prepares, you submit)

1. Sign in to Google Search Console with an account that is Owner or Editor on the production Cloud project.
2. Click Add property, choose Domain, enter example.com and click Continue.
3. Add the shown google-site-verification TXT record to your DNS, wait for propagation, then click Verify.
4. Repeat for every Authorized domain listed on the Branding page.

[Google Search Console](https://search.google.com/search-console) · [Verify your site ownership](https://support.google.com/webmasters/answer/9008080) _[documented s4]_

### 11. Publish the app to In production (1–5 min, you)

1. Do this in your production project, not the dev one.
2. Open Google Auth Platform > Audience and click Publish app, then Confirm.
3. Publishing status changes to In production; test-user list no longer applies. Until scopes are verified, users get the unverified-app screen and count against the lifetime 100-new-user cap - so submit for verification right away and don't request unverified scopes in production code.

[Audience page](https://console.cloud.google.com/auth/audience) · [Manage App Audience](https://support.google.com/cloud/answer/15549945) _[documented s2]_

### 12. Run brand verification and publish branding (5–30 min, you)

1. On the Branding page click Verify Branding. The automated check usually finishes in minutes; branding edits are locked while it runs.
2. If status is Need to fix issues, click View issues, fix them, and request re-verification (or choose 'I believe the issues found are incorrect. Request additional review').
3. When status is Ready to publish, click Publish branding within 7 days or you must re-verify.
4. Brand must be published before you can request data-access (scope) verification.

[Branding page](https://console.cloud.google.com/auth/branding) · [Manage OAuth App Branding (Brand Verification)](https://support.google.com/cloud/answer/15549049) _[documented s3]_

### 13. Submit sensitive/restricted scopes for verification (Verification Center) (4–12 hours, agent prepares, you submit)

1. Record a demo video: English consent screen showing the exact scopes and your app name, the full OAuth flow, and each scope being used in the app. Upload to YouTube as Unlisted.
2. Open Google Auth Platform > Verification Center and click Prepare for verification.
3. Review the pre-filled app info, click Save and Continue, then for each sensitive/restricted scope write a justification naming the user-facing feature and why narrower scopes fail.
4. Paste the YouTube link, then click Submit for verification.
5. Watch the project-owner/editor inboxes; reviewers ask follow-up questions by email and the clock effectively stops until you reply.
6. Remove any OAuth clients in the project that aren't production-ready; all clients in the project are reviewed together.
   - Justification example (from Google): `My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app, so that users can manage their schedules through my app and sync the changes with their Google calendar.`

[Verification Center](https://console.cloud.google.com/auth/verification) · [Submitting your app for verification](https://support.google.com/cloud/answer/13461325) · [Sensitive scope verification](https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification) _[documented s8,s4]_

### 14. Complete the CASA security assessment (restricted scopes) (1–4 weeks, you)

1. Wait for Google Trust & Safety to email you that it is time for the security assessment (it comes after the scope review) and which assurance level (AL1 or AL2) applies.
2. Pick an App Defense Alliance authorized lab, get quotes from several, and contract directly (Google charges nothing; reported costs roughly $500-$4,500/yr).
3. Complete the lab's scans and self-assessment questionnaire; for higher levels grant read-only access to the cloud environment storing Google data (e.g. auditor roles).
4. Remediate all critical/high findings; the lab sends the Letter of Validation/Assessment to Google.
5. Calendar reminder: full re-assessment and re-verification every 12 months from the LOA date.

[Security Assessment (Google)](https://support.google.com/cloud/answer/13465431) · [CASA overview](https://appdefensealliance.dev/casa) · [CASA assurance levels](https://appdefensealliance.dev/casa/casa-tiering) · [Restricted scope verification](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification) _[documented s6,s10]_

## Blockers

- **Users disconnected every 7 days** (medium). Symptom: invalid_grant on refresh roughly a week after users connect; testers must re-authorize. Fix: Expected in External + Testing with any scope beyond openid/email/profile. Use Internal for org-only use, or publish and verify the app. Don't ship Testing-mode clients to real users. _[documented s1]_
- **Lifetime 100-user cap exhausted ('Sign in with Google temporarily disabled')** (high). Symptom: New users can't authorize; consent fails after the unverified-app screen. Fix: The cap applies to the project's lifetime and cannot be reset. Never request unverified sensitive/restricted scopes from production; get verified first. If burned, use a new production project only after verification is approved. _[documented s2]_
- **redirect_uri_mismatch** (medium). Symptom: Error 400: redirect_uri_mismatch on the Google consent page. Fix: Copy the exact redirect_uri your code sends (scheme, host, port, trailing slash) into Authorized redirect URIs on the correct client; use HTTPS unless localhost; no wildcards; wait up to a few hours for propagation. _[documented s9]_
- **Lost client secret** (low). Symptom: Console shows only the last 4 characters of the secret; no download option. Fix: Use Add Secret on the client details page (client secret rotation), deploy the new secret, then Disable and delete the old one. Max two secrets per client. _[documented s9]_
- **OAuth client silently auto-deleted** (medium). Symptom: deleted_client error; existing refresh tokens for that client fail. Fix: Clients unused (no token requests or edits) for six months are deleted after a 30-day email warning. Restore within the recovery window from the Deleted credentials page; keep contact emails monitored. _[documented s9]_
- **Brand verification: 'Need to fix issues' (domain not verified / homepage)** (medium). Symptom: Verify Branding fails; View issues lists domain ownership, homepage or privacy policy problems. Fix: Verify every Authorized domain in Search Console with a project Owner/Editor account; homepage must describe the app (not a login wall) and link the exact privacy policy URL used on the Branding page; app name must not use Google trademarks. _[documented s3]_
- **Scope review rejected for over-broad scopes** (high). Symptom: Reviewer asks you to justify or narrow scopes, e.g. mail.google.com for sending, or drive for file pickers. Fix: Switch to gmail.send for SMTP-style sending, drive.file + Google Picker for user-chosen files, and drop scopes for unbuilt features. Resubmit with updated video. _[documented s15]_
- **Workspace users blocked (admin_policy_enforced / org_internal)** (medium). Symptom: Users in a customer's Workspace can't grant Gmail/Drive scopes even though your app is verified; or external users get org_internal. Fix: For admin_policy_enforced, the customer's admin must mark your client ID Trusted under API controls. For org_internal, your app is set to Internal; switch to External if outsiders need access. _[documented s1]_
- **Verification stuck 'in review' for weeks** (medium). Symptom: No email from Trust & Safety well past the 10-business-day estimate. Fix: Check spam for all owner/editor/contact addresses, reply to the last reviewer email rather than resubmitting, and don't change scopes mid-review. Community threads report multi-week stalls. _[unverified s22]_

## Agent vs. you

**An agent can:**
- Map each agent feature to the narrowest Gmail/Drive/Calendar scope and flag restricted ones
- Enable APIs and create projects via gcloud once you've authenticated the CLI
- Draft the privacy policy, Limited Use disclosure, homepage copy and terms of service
- Write per-scope justifications and a shot-by-shot demo video script
- Implement the authorization-code + PKCE flow, incremental auth, encrypted refresh-token storage and invalid_grant handling
- Validate redirect URIs against Google's rules before you paste them
- Add DNS TXT records for Search Console if given DNS API access
- Run OWASP ASVS / CASA-style scans and fix findings before the lab assessment

**You must:**
- Sign in to Google Cloud console, Search Console and (for Workspace) the Admin console
- Accept the Google API Services User Data Policy and other attestations
- Copy the client secret at creation time into a secret manager
- Publish privacy policy / homepage on your own verified domain
- Record and upload the demo video and click Submit for verification
- Answer reviewer emails sent to project owners/editors
- Choose, contract and pay a CASA lab; grant it access; repeat yearly
- Decide to Publish app (lifetime 100-user cap risk)

## What we couldn't confirm

- Exact current button labels inside the Google Auth Platform 'Get started' wizard and Data Access dialog were taken from the live console as commonly described, not from a verbatim help article; they may differ slightly.
- Calendar scope tiers: the Calendar scopes page did not expose a sensitivity table to our scraper; 'sensitive' is inferred from Calendar's absence from Google's restricted list and Google's own calendar justification example.
- Real-world review times beyond Google's estimates (3-5 weeks sensitive, 3-12 weeks restricted) come from Reddit/forum posts and are unverified.
- CASA cost ($500-$4,500/yr) is from third-party blogs and Reddit, not Google; lab pricing changes.
- Google's FAQ still references 'free tier 2' self-scans and 'Tier 3', while the App Defense Alliance now defines only lab-tested AL1/AL2; which applies to a new submission today could not be confirmed without going through review.
- Whether a client-side-only app (no server touching restricted data) fully avoids CASA in practice was not tested.

## Verification log

- 2026-10-30 · doc-review · **corrected**: Brand verification turnaround. The FAQ (s10) still lists brand verification at '2-3 Business days', but the current Branding help page (s3) describes an automated 'Verify Branding' check that 'usually completes in a few minutes', with Ready to publish / Need to fix issues states and a 7-day window to click Publish branding. Human review is now only a fallback.
- 2026-10-30 · doc-review · **corrected**: CASA tiers and self-scan. Common advice says Tier 1/Tier 2 can be a free self-scan. The ADA assurance-level page (s16) now defines only AL1 and AL2, both 'Lab Tested - Lab Verified', with Google (not the developer) choosing the level. Google's FAQ (s10) still mentions 'free tier 2' and 'Tier 3', so Google's docs are internally inconsistent.
- 2026-10-30 · doc-review · **corrected**: Sensitive scope review time. Older answers (e.g. Server Fault) quote '3-5 days'. Current docs say 'up to 10 days' (s13) and '10 Business days' (s10), and that estimates are not guaranteed.
- 2026-10-30 · doc-review · **confirmed**: Restricted scope review time. Google gives three different framings: '6 weeks' (FAQ s10), 'several weeks' (s12) and 'several months' (unverified apps page s11). We present 6 weeks as the official estimate and 3-12 weeks as the community range.
- 2026-10-30 · doc-review · **corrected**: Client secret retrievability. Many tutorials say you can download the client JSON later. Since mid-2025 secrets are hashed: shown only at creation, then only the last four characters (s9). Recovery is via rotation (Add Secret).
- 2026-10-30 · doc-review · **confirmed**: Unused OAuth client auto-deletion. Clients inactive for six months are deleted automatically with a 30-day email warning; their refresh tokens stop working (s9). Relevant for low-traffic agent integrations.
- 2026-10-30 · doc-review · **confirmed**: AI-agent client designation. New: the client form has a 'Use this client for an AI-powered agent' checkbox; Google asks for separate standard vs agentic client IDs, and some Google MCP endpoints (Workspace tools) only accept agentic clients. Tagging grants no extra scopes or verification shortcuts (s9).
- 2026-10-30 · doc-review · **corrected**: Console naming: 'OAuth consent screen' vs Google Auth Platform. Current help articles (s2, s3, s9) use Google Auth Platform pages: Overview, Branding, Audience, Data Access, Clients, Verification Center. The older 'Submitting your app' article (s8) and FAQ still say 'OAuth Consent Screen' / 'Edit App'. Guide uses the new labels.
- 2026-10-30 · doc-review · **confirmed**: 7-day refresh token expiry in Testing. Applies to External + Testing unless only openid/email/profile are requested (s1, s2). Internal apps are not affected.
- 2026-10-30 · doc-review · **confirmed**: 100-user cap scope. Two different 100s: 100 test users in Testing, and a lifetime 100-new-user cap for apps showing the unverified-app screen, which 'cannot be reset or changed' (s2, s10). Personal-use exemption is also defined as fewer than 100 users (s7).
- 2026-10-30 · doc-review · **confirmed**: Drive restricted scope list. Restricted Drive scopes include drive.metadata and drive.metadata.readonly as well as drive, drive.readonly, drive.activity*, drive.scripts and drive.meet.readonly (s5). drive.file and drive.appdata are recommended non-sensitive alternatives (s14).
- 2026-10-30 · doc-review · **corrected**: Gmail sending via SMTP with mail.google.com. Common advice is to use mail.google.com for IMAP/SMTP. Google's FAQ says using it just to send via SMTP violates minimum-scope policy; use the sensitive gmail.send scope via the Gmail API instead (s10, s15).
- 2026-10-30 · doc-review · **confirmed**: When CASA applies. Assessment is required when restricted data is accessed from or through a third-party server (s12); Drive guide says the same for data stored or transmitted via servers (s14). Google charges nothing; the developer pays the lab (s10).
- 2026-10-30 · doc-review · **confirmed**: Limited Use and AI training. Google user data may only feed personalized models for user-facing features and may not train or improve foundation/frontier models (s10). Demo video must show explicit consent if data is used for personalized model training (s4).
- 2026-10-30 · http-probe · **confirmed**: Automated: developer console (https://console.cloud.google.com/auth/overview). Console is live and sits behind sign-in: redirected to accounts.google.com. An agent cannot go further without your account.
- 2026-10-30 · http-probe · **confirmed**: Automated: OIDC discovery document (https://accounts.google.com/.well-known/openid-configuration). Discovery document found. authorization_endpoint=https://accounts.google.com/o/oauth2/v2/auth; token_endpoint=https://oauth2.googleapis.com/token; PKCE methods: plain, S256; scopes: openid, email, profile.
- 2026-10-30 · http-probe · **confirmed**: Automated: authorize endpoint with a fake client_id (https://accounts.google.com/o/oauth2/v2/auth). Endpoint is live; responded 302 redirecting to accounts.google.com (usually sign-in before client validation).
- 2026-10-30 · doc-review · **confirmed**: Automated: 40 quotes re-fetched and matched against their cited pages. 40 of 40 quotes found verbatim in the live page HTML.  22/22 source URLs returned HTTP 200.

## Sources

- s1: [Using OAuth 2.0 to Access Google APIs](https://developers.google.com/identity/protocols/oauth2) (official-docs, accessed 2026-10-30)
- s2: [Manage App Audience](https://support.google.com/cloud/answer/15549945) (official-docs, accessed 2026-10-30)
- s3: [Manage OAuth App Branding](https://support.google.com/cloud/answer/15549049) (official-docs, accessed 2026-10-30)
- s4: [Verification requirements](https://support.google.com/cloud/answer/13464321) (official-policy, accessed 2026-10-30)
- s5: [Restricted Scopes](https://support.google.com/cloud/answer/13464325) (official-policy, accessed 2026-10-30)
- s6: [Security Assessment](https://support.google.com/cloud/answer/13465431) (official-policy, accessed 2026-10-30)
- s7: [When is verification not needed](https://support.google.com/cloud/answer/13464323) (official-policy, accessed 2026-10-30)
- s8: [Submitting your app for verification](https://support.google.com/cloud/answer/13461325) (official-docs, accessed 2026-10-30)
- s9: [Manage OAuth Clients](https://support.google.com/cloud/answer/15549257) (official-docs, accessed 2026-10-30)
- s10: [OAuth App Verification - Frequently Asked Questions](https://support.google.com/cloud/answer/13463817) (official-docs, accessed 2026-10-30)
- s11: [Unverified apps](https://support.google.com/cloud/answer/7454865) (official-docs, accessed 2026-10-30)
- s12: [Restricted scope verification](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification) (official-docs, accessed 2026-10-30)
- s13: [Sensitive scope verification](https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification) (official-docs, accessed 2026-10-30)
- s14: [Choose Google Drive API scopes](https://developers.google.com/workspace/drive/api/guides/api-specific-auth) (official-docs, accessed 2026-10-30)
- s15: [Choose Gmail API scopes](https://developers.google.com/workspace/gmail/api/auth/scopes) (official-docs, accessed 2026-10-30)
- s16: [CASA Assurance Levels (App Defense Alliance)](https://appdefensealliance.dev/casa/casa-tiering) (official-docs, accessed 2026-10-30)
- s17: [Choose Google Calendar API scopes](https://developers.google.com/workspace/calendar/api/auth) (official-docs, accessed 2026-10-30)
- s18: [Reddit r/googlecloud: Got Google OAuth verified in 3 weeks with restricted scopes](https://www.reddit.com/r/googlecloud/comments/1moptdt/got_google_oauth_verified_in_3_weeks_with/) (community, accessed 2026-10-30)
- s19: [Reddit r/SaaS: Google Restricted Scope OAuth Hell (8-12 weeks)](https://www.reddit.com/r/SaaS/comments/1wbasx0/hit_the_final_boss_of_saas_google_restricted/) (community, accessed 2026-10-30)
- s20: [DeepStrike: Google CASA guide (costs)](https://deepstrike.io/blog/google-casa-security-assessment-2025) (community, accessed 2026-10-30)
- s21: [Reddit r/googlecloud: Gmail CASA Tier 2 assessment experiences](https://www.reddit.com/r/googlecloud/comments/18gbu2a/has_anyone_done_the_gmail_casa_tier_2_assessment/) (community, accessed 2026-10-30)
- s22: [Google Developer forum: OAuth verification stuck 'in review' since April 2026](https://discuss.google.dev/t/oauth-verification-stuck-in-review-since-april-2026-sensitive-scopes-only-no-trust-safety-email-received/374317) (community, accessed 2026-10-30)
- p1: [Live probe (console): Console is live and sits behind sign-in: redirected to accounts.google.com. An agent cannot go furth](https://console.cloud.google.com/auth/overview) (probe, accessed 2026-10-30)
- p2: [Live probe (oidc-discovery): Discovery document found. authorization_endpoint=https://accounts.google.com/o/oauth2/v2/auth; token](https://accounts.google.com/.well-known/openid-configuration) (probe, accessed 2026-10-30)
- p3: [Live probe (authorize-endpoint): Endpoint is live; responded 302 redirecting to accounts.google.com (usually sign-in before client va](https://accounts.google.com/o/oauth2/v2/auth) (probe, accessed 2026-10-30)

Evidence tags: tested = exercised live; documented = official source, quote checked; inferred = reasoning; unverified = unconfirmed.