How should an early-stage Gmail client choose OAuth flow to pass verification without premature CASA costs?

Google Workspace Developers Q&A
1

Hi everyone,

I’m building an alternative Gmail client with a specific workflow approach.

At minimum, the app needs scopes beyond read-only: users must be able to mark messages as read, archive, and send emails. That means I need sensitive scopes such as gmail.modify and gmail.send.

I’m stuck between two OAuth architecture options and I’m finding contradictory advice online.

Option A: Client-side authorization

  • Use Google Identity Services in the browser.

  • Access token is stored only client-side (memory + IndexedDB).

  • No Gmail data or OAuth tokens are stored on my backend.

Pros: better privacy model, simpler backend, lower initial cost.

Concern: In GCP I get the warning:

“Your app is not configured to use secure OAuth flows and may be vulnerable to impersonation.”

I’m worried this may negatively affect OAuth verification approval.

Option B: Backend authorization

  • Backend handles OAuth code exchange, stores access/refresh tokens, and proxies Gmail API requests.

  • This is generally considered more secure and “enterprise-ready”.

Pros: likely stronger verification posture.

Concern: this path may require heavier compliance/security work (including CASA-related expectations/costs), which is expensive for an early-stage product before product-market validation.

My practical dilemma:

  • I want to validate the product hypothesis with real users first.

  • Staying in Testing mode with manually added users is not enough for meaningful validation and early revenue.

  • But moving too early to a full backend + costly security assessment may be financially risky before demand is proven.

Questions

  1. For Gmail API verification, is a client-side GIS token flow (with best practices like incremental auth, least privilege, etc.) realistically approvable for production in this scenario?

  2. Is the “secure OAuth flows / impersonation” warning effectively a blocker for verification, or a recommendation?

  3. What is the most practical phased path that Google reviewers typically accept for early-stage apps (to launch safely first, then move to stronger architecture later)?

  4. If backend OAuth is strongly preferred, what is the minimum acceptable implementation to reduce impersonation risk while keeping initial cost manageable?

Any guidance from people who have passed Gmail scope verification recently (or from reviewers) would be greatly appreciated.

Thanks!

1 Like
2

Hi @Kein You can pass Gmail verification with a client-side architecture if it’s implemented correctly.

Key points:

  • Use Authorization Code flow with PKCE, not the old implicit flow.

  • Request only the scopes you truly need.

  • Do not store Gmail data or tokens on your server.

  • Clearly explain your data flow during the verification process.

The “secure OAuth flows” warning is not an automatic rejection. It’s mainly a recommendation. If you use PKCE properly, it is generally acceptable.