Google (Gmail, Drive, Calendar)

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

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.

• Google account + Google Cloud projectDocumented(1)

  Any Google account can create a project; no billing is required for Gmail/Drive/Calendar APIs. Use separate projects for development/testing and production.

• Google Workspace / Cloud Identity organization owning the projectDocumented(1)

  Required only for the Internal user type; the project must sit under the org (check IAM & Admin > Settings > Location).

• Homepage, privacy policy and terms of service on a domain you ownDocumented(1)

  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.

• Verified domain ownership (Google Search Console)Documented(1)

  Every Authorized Domain must be verified in Google Search Console by an account that is an Owner or Editor on the Cloud project.

• App logo (optional but triggers verification)Documented(1)

  Square 120x120 px, <=1 MB, JPG/PNG/BMP. Name and logo appear on the consent screen only after brand verification.

• Scope justificationDocumented(1)

  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.

• Demo videoDocumented(1)

  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.

• Limited Use compliance (incl. AI training restrictions)Documented(1)

  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.

• CASA security assessment (annual, paid to lab)Documented(2)

  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.

• Up-to-date project contactsDocumented(1)

  All verification communication goes by email to project owners/editors and the developer contact emails; missed emails can cost API access.

1. 1

   Create a Google Cloud project

   About 2–5 min

   You do this

   Requires your Google login. An agent with an authenticated gcloud CLI could run `gcloud projects create`, but most developers do this in the console.

   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.
   Documented(1)Creating and managing projectsSubmitting your app for verification (project setup)Pointer ready: highlights “Project name”
2. 2

   Enable the Gmail, Google Drive and Google Calendar APIs

   About 2–5 min

   Agent prepares, you submit

   Click-through in the console, or an agent can run `gcloud services enable gmail.googleapis.com drive.googleapis.com calendar-json.googleapis.com` once you have authenticated gcloud.

   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.
   Documented(1)API LibrarySubmitting your app for verification (enable APIs)Pointer ready: highlights “Search for APIs & Services”
3. 3

   Register the app in Google Auth Platform (formerly 'OAuth consent screen')

   About 5–10 min

   You do this

   Requires your Google login and accepting the Google API Services User Data Policy, which is a legal attestation.

   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.
   Documented(2)Google Auth Platform overviewManage OAuth App BrandingManage App AudiencePointer ready: highlights “Get started”
4. 4

   Fill in Branding: links, logo and Authorized domains

   About 30–180 min

   Agent prepares, you submit

   An agent can draft the privacy policy / ToS text and homepage copy; you must publish them on your domain and enter them in the console.

   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.comCopy

   Top private domain only; subdomains are then allowed.

   Application privacy policy link

   https://example.com/privacyCopy

   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.Copy

   Sample wording provided in Google's FAQ.

   Documented(1)Branding pageManage OAuth App BrandingVerification requirementsPointer ready: highlights “Add domain”
5. 5

   Declare scopes on the Data Access page (pick the narrowest)

   About 10–30 min

   Agent prepares, you submit

   An agent can map features to the narrowest scopes and write the justifications; you click them in the console.

   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.fileCopy

   Sensitive Gmail send

   https://www.googleapis.com/auth/gmail.sendCopy

   Sensitive Calendar events

   https://www.googleapis.com/auth/calendar.eventsCopy

   Classification inferred: Calendar scopes are absent from Google's restricted list.

   Restricted Gmail read

   https://www.googleapis.com/auth/gmail.readonlyCopy

   Triggers CASA if data reaches your servers.

   Documented(2)Data Access pageRestricted scopes listChoose Gmail API scopesChoose Drive API scopesChoose Calendar API scopesPointer ready: highlights “Add or remove scopes”
6. 6

   Add test users (External apps in Testing)

   About 2–10 min

   You do this

   Requires your console login; you must know each tester's Google account email.

   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.
   Documented(1)Audience pageManage App AudiencePointer ready: highlights “Add users”
7. 7

   Create the OAuth client (Web application) and register redirect URIs

   About 5–10 min

   You do this

   Requires console login; the client secret is shown only once, so a human must copy it into your secret manager.

   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 applicationCopy

   Authorized redirect URIs

   https://app.example.com/oauth/google/callbackCopy

   Production callback; must match the redirect_uri parameter byte-for-byte.

   Authorized redirect URIs (dev)

   http://localhost:3000/oauth/google/callbackCopy

   Plain HTTP allowed only for localhost; better in the separate dev project.

   Documented(1)Clients pageManage OAuth ClientsOAuth 2.0 for Web Server ApplicationsPointer ready: highlights “Create client”
8. 8

   Implement the authorization-code flow and token storage

   About 1–4 hours

   An agent can do this

   Pure code work: an AI agent can write and test this against your test users.

   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.
   Documented(1)Using OAuth 2.0 to Access Google APIsOAuth 2.0 for Web Server Applications
9. 9

   (Internal / Workspace customers) Have a Workspace admin trust the app

   About 5–15 min

   You do this

   Requires a Google Workspace super admin login (yours or your customer's).

   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.
   Documented(1)Control which third-party & internal apps access Google Workspace dataManage App Audience (Internal)Pointer ready: highlights “Manage Third-Party App Access”
10. 10

    Verify your domain in Google Search Console

    About 10–60 min

    Agent prepares, you submit

    You must log in with a project Owner/Editor account; an agent with DNS API access can add the TXT record.

    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.
    Documented(1)Google Search ConsoleVerify your site ownershipPointer ready: highlights “Add property”
11. 11

    Publish the app to In production

    About 1–5 min

    You do this

    Console action by the project owner; irreversible-feeling public launch decision.

    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.
    Documented(1)Audience pageManage App AudiencePointer ready: highlights “Publish app”
12. 12

    Run brand verification and publish branding

    About 5–30 min

    You do this

    Console action; an agent can pre-check homepage/privacy-policy compliance.

    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.
    Documented(1)Branding pageManage OAuth App Branding (Brand Verification)Pointer ready: highlights “Verify Branding”
13. 13

    Submit sensitive/restricted scopes for verification (Verification Center)

    About 4–12 hours

    Agent prepares, you submit

    An agent can draft scope justifications and a video script; you must record the demo video, upload it to YouTube and click 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.Copy

    Documented(2)Verification CenterSubmitting your app for verificationSensitive scope verificationPointer ready: highlights “Prepare for verification”
14. 14

    Complete the CASA security assessment (restricted scopes)

    About 1–4 weeks

    You do this

    Requires contracting and paying an authorized lab, giving them access to your app/infra, and remediating findings.

    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.
    Documented(2)Security Assessment (Google)CASA overviewCASA assurance levelsRestricted scope verification

• Users disconnected every 7 daysDocumented(1)

  You'll see: invalid_grant on refresh roughly a week after users connect; testers must re-authorize.

  Do this: 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.

• Lifetime 100-user cap exhausted ('Sign in with Google temporarily disabled')Documented(1)

  You'll see: New users can't authorize; consent fails after the unverified-app screen.

  Do this: 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.

• redirect_uri_mismatchDocumented(1)

  You'll see: Error 400: redirect_uri_mismatch on the Google consent page.

  Do this: 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.

• Lost client secretDocumented(1)

  You'll see: Console shows only the last 4 characters of the secret; no download option.

  Do this: 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.

• OAuth client silently auto-deletedDocumented(1)

  You'll see: deleted_client error; existing refresh tokens for that client fail.

  Do this: 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.

• Brand verification: 'Need to fix issues' (domain not verified / homepage)Documented(1)

  You'll see: Verify Branding fails; View issues lists domain ownership, homepage or privacy policy problems.

  Do this: 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.

• Scope review rejected for over-broad scopesDocumented(1)

  You'll see: Reviewer asks you to justify or narrow scopes, e.g. mail.google.com for sending, or drive for file pickers.

  Do this: 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.

• Workspace users blocked (admin_policy_enforced / org_internal)Documented(1)

  You'll see: Users in a customer's Workspace can't grant Gmail/Drive scopes even though your app is verified; or external users get org_internal.

  Do this: 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.

• Verification stuck 'in review' for weeksUnverified(1)

  You'll see: No email from Trust & Safety well past the 10-business-day estimate.

  Do this: 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.

• CorrectedBrand verification turnaroundThe 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.Read against official docs, 2026-10-30
• CorrectedCASA tiers and self-scanCommon 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.Read against official docs, 2026-10-30
• CorrectedSensitive scope review timeOlder 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.Read against official docs, 2026-10-30
• ConfirmedRestricted scope review timeGoogle 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.Read against official docs, 2026-10-30
• CorrectedClient secret retrievabilityMany 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).Read against official docs, 2026-10-30
• ConfirmedUnused OAuth client auto-deletionClients 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.Read against official docs, 2026-10-30
• ConfirmedAI-agent client designationNew: 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).Read against official docs, 2026-10-30
• CorrectedConsole naming: 'OAuth consent screen' vs Google Auth PlatformCurrent 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.Read against official docs, 2026-10-30
• Confirmed7-day refresh token expiry in TestingApplies to External + Testing unless only openid/email/profile are requested (s1, s2). Internal apps are not affected.Read against official docs, 2026-10-30
• Confirmed100-user cap scopeTwo 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).Read against official docs, 2026-10-30
• ConfirmedDrive restricted scope listRestricted 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).Read against official docs, 2026-10-30
• CorrectedGmail sending via SMTP with mail.google.comCommon 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).Read against official docs, 2026-10-30
• ConfirmedWhen CASA appliesAssessment 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).Read against official docs, 2026-10-30
• ConfirmedLimited Use and AI trainingGoogle 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).Read against official docs, 2026-10-30
• ConfirmedAutomated: 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.Live HTTP probe, 2026-10-30
• ConfirmedAutomated: 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.Live HTTP probe, 2026-10-30
• ConfirmedAutomated: 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).Live HTTP probe, 2026-10-30
• ConfirmedAutomated: 40 quotes re-fetched and matched against their cited pages40 of 40 quotes found verbatim in the live page HTML. 22/22 source URLs returned HTTP 200.Read against official docs, 2026-10-30

• 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.

1. s1Using OAuth 2.0 to Access Google APIs (official docs, accessed 2026-10-30)
2. s2Manage App Audience (official docs, accessed 2026-10-30)
3. s3Manage OAuth App Branding (official docs, accessed 2026-10-30)
4. s4Verification requirements (official policy, accessed 2026-10-30)
5. s5Restricted Scopes (official policy, accessed 2026-10-30)
6. s6Security Assessment (official policy, accessed 2026-10-30)
7. s7When is verification not needed (official policy, accessed 2026-10-30)
8. s8Submitting your app for verification (official docs, accessed 2026-10-30)
9. s9Manage OAuth Clients (official docs, accessed 2026-10-30)
10. s10OAuth App Verification - Frequently Asked Questions (official docs, accessed 2026-10-30)
11. s11Unverified apps (official docs, accessed 2026-10-30)
12. s12Restricted scope verification (official docs, accessed 2026-10-30)
13. s13Sensitive scope verification (official docs, accessed 2026-10-30)
14. s14Choose Google Drive API scopes (official docs, accessed 2026-10-30)
15. s15Choose Gmail API scopes (official docs, accessed 2026-10-30)
16. s16CASA Assurance Levels (App Defense Alliance) (official docs, accessed 2026-10-30)
17. s17Choose Google Calendar API scopes (official docs, accessed 2026-10-30)
18. s18Reddit r/googlecloud: Got Google OAuth verified in 3 weeks with restricted scopes (community, accessed 2026-10-30)
19. s19Reddit r/SaaS: Google Restricted Scope OAuth Hell (8-12 weeks) (community, accessed 2026-10-30)
20. s20DeepStrike: Google CASA guide (costs) (community, accessed 2026-10-30)
21. s21Reddit r/googlecloud: Gmail CASA Tier 2 assessment experiences (community, accessed 2026-10-30)
22. s22Google Developer forum: OAuth verification stuck 'in review' since April 2026 (community, accessed 2026-10-30)
23. p1Live probe (console): Console is live and sits behind sign-in: redirected to accounts.google.com. An agent cannot go furth (probe, accessed 2026-10-30)
24. p2Live probe (oidc-discovery): Discovery document found. authorization_endpoint=https://accounts.google.com/o/oauth2/v2/auth; token (probe, accessed 2026-10-30)
25. p3Live probe (authorize-endpoint): Endpoint is live; responded 302 redirecting to accounts.google.com (usually sign-in before client va (probe, accessed 2026-10-30)