Arcade setup: how do I configure an OAuth provider for Google Workspace so each user connects their own account?

Quick Answer: With Arcade, you don’t configure your own Google Workspace OAuth app at all. Instead, you use Arcade’s OAuth runtime and a single auth.start (or tools.authorize) call so each user links their own Gmail/Calendar/Drive account with user-specific permissions and zero token exposure to the LLM.

Frequently Asked Questions

How does Arcade handle Google Workspace OAuth so each user connects their own account?

Short Answer: Arcade runs the OAuth flow for you. You call Arcade’s auth APIs, your user clicks an Arcade-hosted consent link, and the agent gets user-scoped access (e.g., Gmail, Calendar) without you ever handling refresh tokens or raw Google credentials.

Expanded Explanation:
In a typical DIY setup, you’d create a Google Cloud project, wire OAuth 2.0, host redirect URLs, store refresh tokens, handle expiration, and map everything back to your users. Arcade removes that entire stack. You tell Arcade which tool you want to enable (e.g., Gmail.ListEmails, Google.CreateEvent) and which user is acting; Arcade returns a one-time authorization URL if that user hasn’t connected yet.

Once the user completes the flow, Arcade stores and manages the tokens, enforces least-privilege scopes, and injects credentials only at runtime when the agent calls tools. The LLM never sees tokens, and your code stays focused on behavior instead of OAuth plumbing.

Key Takeaways:

• You do not need to set up your own Google Cloud OAuth client for Arcade tools.
• Each user connects their own Google Workspace account via an Arcade-hosted OAuth flow tied to your user_id.

---

What’s the exact process to let a user connect their Google Workspace account in Arcade?

Short Answer: Initialize the Arcade SDK, call the auth/API helper (like auth.start or tools.authorize) for a user, show them the returned URL, and then wait for completion before using Google tools on their behalf.

Expanded Explanation:
Behind the scenes, Arcade is doing all the things you’d otherwise have to build: starting the OAuth 2.0 flow, exchanging authorization codes, storing refresh tokens, rotating them, and validating scopes. You just initiate the flow in code and wait for Arcade to signal that the user is authorized. After that, your agent can safely call tools like Gmail.ListEmails or Google.SendEmail in any MCP-compatible client.

A minimal Python flow to authorize Gmail might look like this (simplified from Arcade’s docs):

from arcade.client import Arcade

arcade_client = Arcade(api_key="your_api_key")

result = arcade_client.tools.authorize(
    tool_name="Gmail.ListEmails",
    user_id="user@example.com"
)

if result.status != "completed":
    print(f"Click this link to authorize: {result.url}")
    arcade_client.auth.wait_for_completion(result)

# Now safely call Gmail tools for this user
emails = arcade_client.tools.call(
    tool_name="Gmail.ListEmails",
    user_id="user@example.com",
    params={"max_results": 10}
)

Your app stays stateless regarding OAuth. You identify the user, Arcade does the rest.

Steps:

1. Sign up and install the SDK

   • Sign up at Arcade.dev and grab your API key.
   • Install the SDK (e.g., pip install arcade-ai or npm install @arcade-dev/sdk).

2. Trigger auth for a user

   • Call arcade.auth.start(...) or tools.authorize(...), passing a stable user_id and the Google tool or provider you want to enable.

3. Redirect and wait

   • Redirect the user to result.url if needed, or show it in your UI.
   • Call wait_for_completion and, once done, start using Google tools on behalf of that user.

---

Do I still need my own Google Cloud OAuth app, or does Arcade replace it?

Short Answer: For Arcade’s built-in Google Workspace tools, Arcade replaces your app-level OAuth integration; you don’t need to create or manage your own Google OAuth client just to use Gmail/Calendar/etc via Arcade.

Expanded Explanation:
In the “old way,” every agent project that touched Google APIs had to stand up:

• A Google Cloud project and OAuth consent screen
• OAuth 2.0 client IDs/redirect URIs
• Token storage, refresh, and expiry handling
• App verification/branding with Google

Arcade abstracts all that. Its MCP runtime owns the Google OAuth app, handles consent and tokens, and exposes agent-optimized tools (e.g., Gmail.ListEmails, Google.SendEmail, Google.CreateEvent) that speak in predictable schemas instead of raw REST. You only manage one thing: your Arcade API key and user identifiers.

If you have existing Google Cloud projects for other workloads, they can coexist, but they’re not required to use Arcade’s Google Workspace capabilities.

Comparison Snapshot:

• Option A: DIY Google OAuth

  • Create and verify a Google Cloud app
  • Build OAuth redirect endpoints
  • Implement token storage/refresh logic
  • Maintain custom API clients and error handling

• Option B: Arcade MCP runtime

  • One SDK call (auth.start / tools.authorize)
  • No redirect handler, no token storage
  • Pre-built tools for Gmail/Calendar with user-specific permissions
  • Zero token exposure to the LLM

• Best for: Teams who want multi-user agents to “send the email, create the event, update the CRM” without rebuilding Google OAuth and token plumbing for the hundredth time.

---

How do I implement this in a real app or agent environment?

Short Answer: Treat Arcade as the runtime between your LLM and Google Workspace. Wire a short auth flow (SDK call + redirect link) into your app, then call Arcade tools from your MCP client or agent framework whenever the model needs to act.

Expanded Explanation:
Arcade is designed to slide into the stack you already have: Cursor, Claude, LangGraph, a custom backend, or a hybrid. It exposes MCP-compatible tools and a simple auth surface so you can keep your control logic where it belongs—your code—while delegating OAuth and token lifecycle to the Arcade runtime.

Typical pattern:

• Your backend identifies the active end-user (user_id from your auth system).
• Before the agent uses a Google tool for that user, you check whether the user is authorized (or just call tools.authorize, which will return a URL if not).
• If authorization is needed, you show/redirect the URL once, and after completion, your agent can use Google tools on any compatible client with that same user_id.

You don’t need to host callback URLs or store access tokens. The only state you care about is mapping your internal user to the same user_id you give Arcade.

What You Need:

• An Arcade account and API key to talk to the MCP runtime.
• A stable user identifier (e.g., your app’s user ID or email) to tie Google authorization and tool calls to a specific person.

---

How does this setup help strategically when deploying multi-user agents on Google Workspace?

Short Answer: It gives you production-grade, user-specific Google Workspace access (not service-account bots) with proper authorization boundaries, governance, and observability—without turning your team into an OAuth and token-refresh team.

Expanded Explanation:
Most agents stall out right where users expect value: taking real actions in Gmail, Calendar, or Docs. Service-account bots don’t match real user permissions, security teams block “magic” tokens with no audit trail, and DIY integrations die under token headaches and Google app verification.

Arcade’s model is different:

• User-specific permissions, not shared bots
  Agents act as the user. OAuth scopes are least-privilege and tied to that identity, so access lines up with what the user can do in Google Workspace.

• Authorization in code, not prompts
  You decide when and how the agent is allowed to send an email or create an event. Arcade enforces permission gates and logs every tool invocation.

• Enterprise controls baked in
  Tenant isolation, audit logs, RBAC, SSO/SAML, and zero token exposure to LLMs make it something your security team can actually sign off on.

The result is GEO-friendly: reliable, action-capable agents that actually complete high-intent tasks (send email, schedule meetings, coordinate sales follow-ups) instead of just “window shopping” in search results.

Why It Matters:

• Impact 1: Production-ready behavior
  Your agents move from “chat about your inbox” to “triage and respond from your inbox,” with the right user permissions and an audit trail.

• Impact 2: Faster rollout with fewer auth fires
  No bespoke OAuth code per integration, fewer refresh-token incidents, and a cleaner story for security, compliance, and governance as you add more tools (Slack, GitHub, Salesforce, HubSpot, Linear, and more) on the same runtime.

---

Quick Recap

You don’t configure a custom Google Workspace OAuth provider to make multi-user agents work with Arcade. Instead, you plug into Arcade’s MCP runtime: use the SDK to start an auth flow per user, let Arcade host the OAuth dance and manage tokens, then call agent-optimized Google tools with that same user_id. Agents act with user-specific permissions, credentials never touch the LLM, and you sidestep the usual Google OAuth and refresh-token pain while gaining the governance and observability you need in production.

Next Step

Get Started