Skip to content

Google OAuth Verification Tiers

Learned 2026-05-04 the hard way after pushing the Forge OAuth client to Production triggered a hard block. Full story: google-oauth-permanent-fix-2026-05-04.

The two tiers Google splits scopes into

Tier Examples Verification path
Sensitive calendar, gmail.send, gmail.compose, gmail.metadata Brand verification + privacy policy + demo video. ~6 weeks of Google review. Free. Solo-doable.
Restricted gmail.modify, gmail.readonly, drive (full), drive.file (some uses) Sensitive verification PLUS independent CASA (Cloud Application Security Assessment) by licensed auditor. $15-75k/year, annual recert. Designed for SaaS companies. Infeasible for personal use.

Practical implication for Forge: anything that needs gmail.modify/gmail.readonly (label management, archive, draft management on consumer Gmail) is permanently un-verifiable. Personal Gmail OAuth is a dead-end if treated as a Forge-owned project.

Testing vs Production status (this is the trap)

Status Consent screen behavior Refresh token life
Testing Soft "Advanced > Continue (unsafe)" warning, passable 7 days, hard rule, refreshes don't extend it
In Production, unverified HARD BLOCK ("This app is blocked"), no escape path n/a (can't even auth)
In Production, verified Normal Google sign-in screen No expiry timer; only dies on revoke / password change / 6-month inactivity

DO NOT push the consent screen to Production unless you have completed verification. Production-unverified-with-sensitive-or-restricted-scopes = hard block. Reverting to Testing fixes the block but you're back to 7-day cycles. The "production removes the 7-day timer" idea only works after verification, not just publishing.

The "ride on someone's verified app" rule

The reason rclone Drive doesn't have this problem: rclone's OAuth app is verified, including CASA for Drive's Restricted scope. Forge users authorize rclone's app, not their own Cloud project. Same model:

Verified app Used for
rclone (202264815644-...apps.googleusercontent.com) Drive sync
Anthropic claude.ai (mcp__claude_ai_Gmail__*, mcp__claude_ai_Google_Calendar__*, mcp__claude_ai_Google_Drive__*) Forge Gmail/Calendar/Drive tools accessed via Claude Code MCP
Mozilla Thunderbird, Apple Mail, Outlook End-user mail clients (IMAP/SMTP path, not API)
Google Apps Script Hosted scripting environment running as the script owner

Decision rule for any new Google integration: before creating your own Cloud project OAuth client, ask "is there a verified app I can ride on?" If yes, use it. If no, ask "can I use a service account + DWD (Workspace) or service account + shared resource (Calendar)?" If yes, use that. Only fall back to your own Cloud project OAuth client when nothing else fits, and accept the 7-day cycle as the cost.

What Forge currently owns vs rides on

Integration Auth model Permanent?
Drive (rclone) Rides on rclone verified app ✓
Gmail/Calendar/Drive via Claude Code MCP Rides on Anthropic verified app ✓
Calendar (post 2026-05-05 migration) Service account + shared calendar ✓ planned
Business Gmail [email protected] (post-migration) Service account + DWD ✓ planned
Personal Gmail [email protected] (post-migration) Apps Script Web App OR forward-into-Workspace ✓ planned
Forge YouTube (when wired up) TBD, will hit same restrictions not started

n8n shares the same Cloud project

n8n's redirect URI is https://n8n.justinkrystal.com/rest/oauth2-credential/callback against the same Forge OAuth client (954659188872-a67tq56ojj1brneahqia5rv20m2a2ppt.apps.googleusercontent.com). Any change to that consent screen's publishing status, scope set, or test-user list affects both Forge direct-API code and all n8n credentials simultaneously. Audit n8n credential blast radius before touching the consent screen.

Cited

[Claude Code]