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

Most teams wire Google Workspace into their agent once, behind a service account, and call it a day. It works in the demo—and immediately falls apart when you need user-specific permissions, auditability, and security sign-off. With Arcade, you configure Google OAuth once in the Arcade dashboard, then let each user connect their own Gmail, Calendar, or Drive via a simple auth link, with zero tokens ever touching the LLM.

Quick Answer: Configure Google Workspace OAuth once in Arcade (using your Google Cloud client ID/secret and redirect URL), then call auth.start or tools.authorize per user so each person grants access for their own account. Arcade handles OAuth redirects, token storage/refresh, and injects scoped credentials at tool execution time.

Frequently Asked Questions

How does Arcade make each user connect their own Google Workspace account?

Short Answer: You wire your Google OAuth app into Arcade, then Arcade gives you per-user auth links so each person grants access to their own account, not a shared service account.

Expanded Explanation:
Arcade sits between your agent and Google Workspace as the MCP runtime. You bring your Google Cloud OAuth client (or use Arcade’s managed provider, depending on your plan), register it in Arcade, and specify which tools (e.g., Gmail.ListEmails, Google.SendEmail, Google.CreateEvent) require Google authentication. When your agent needs to act on behalf of a user, it either:

• Calls arcade.auth.start(user_id, "google", …) to kick off a just-in-time OAuth flow, or
• Uses arcade_client.tools.authorize(tool_name="Gmail.ListEmails", user_id="user@example.com") to get an auth link for that specific tool.

The user clicks once, approves the requested scopes in Google’s consent screen, and Arcade stores/rotates tokens behind the scenes. From then on, every tool call runs with that user’s permissions—no service accounts, no shared superuser.

Key Takeaways:

• Configure Google OAuth once in Arcade, then reuse it across many users.
• Each user connects their own Workspace account; Arcade enforces user-specific permissions on every tool call.

---

What’s the step-by-step process to configure Google Workspace OAuth in Arcade?

Short Answer: Create a Google Cloud OAuth client, plug the client ID/secret and redirect URI into Arcade, then generate per-user auth links from your code or MCP client.

Expanded Explanation:
You do a one-time OAuth setup in Google Cloud, then hand the details to Arcade so it can act as the runtime between your agent and Google. After that, your code only deals with a high-level auth.start or tools.authorize call; Arcade handles the redirect dance, token storage, and refresh logic.

Steps:

1. Create a Google Cloud Project & OAuth Client
   • Go to Google Cloud Console → APIs & Services → Credentials.
   • Create (or select) a project.
   • Click Create Credentials → OAuth client ID.
   • Choose Web application and set an OAuth 2.0 client.
2. Configure Redirect URI for Arcade
   • In the same OAuth client, add Arcade’s redirect URI (from the Arcade dashboard) to Authorized redirect URIs.
   • Save the configuration and copy the Client ID and Client Secret.
3. Register Google Workspace in Arcade
   • In the Arcade dashboard, go to Auth / Providers (name may vary by plan).
   • Add a Google provider and paste your Client ID and Client Secret.
   • Select the scopes you need (e.g., Gmail read/send, Calendar read/write). Arcade encourages least-privilege scopes.
4. Initialize Arcade in Your App
   • Install the SDK:

     pip install arcade-ai
     # or
     npm install @arcade-dev/sdk
     

   • Instantiate the client:

     from arcade.client import Arcade
     arcade_client = Arcade(api_key="your_api_key")
     

5. Trigger User-Specific Auth
   • In Python using tools-based authorization:

     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)
     

   • Or in Node using auth.start:

     import { Arcade } from "@arcade-dev/sdk";
     
     const arcade = new Arcade({ apiKey: process.env.ARCADE_API_KEY! });
     
     const authResponse = await arcade.auth.start(
       "user@example.com",
       "google",
       {
         scopes: [
           "https://www.googleapis.com/auth/gmail.readonly",
           "https://www.googleapis.com/auth/calendar.events",
         ],
       }
     );
     
     console.log("Send user to:", authResponse.url);
     // Wait for Arcade to complete OAuth behind the scenes
     

6. Call Google Tools as the User
   • Once authorized, your agent calls tools like Gmail.ListEmails, Google.SendEmail, or Google.CreateEvent.
   • Arcade injects the right token at runtime and keeps it fresh—no token plumbing in your code.

---

What’s the difference between using Arcade vs a raw Google service account or DIY OAuth?

Short Answer: Service accounts act as a shared bot; DIY OAuth makes you own every redirect and refresh token; Arcade gives you user-specific permissions, OAuth done right, and MCP-native tools without exposing tokens to the model.

Expanded Explanation:
Service accounts are tempting because they’re “one credential and done,” but they’re fundamentally wrong for multi-user agents: every action runs with the same broad permissions, and security teams eventually block the rollout. DIY OAuth gets you closer to user-specific access, but you’re now maintaining redirect handlers, token storage, refresh logic, and Google’s increasingly strict verification requirements.

Arcade moves this work into an MCP runtime optimized for agents. You:

• Keep a clean, SDK-level interface (auth.start, tools.authorize, Google.SendEmail) instead of homegrown OAuth code.
• Let Arcade manage tokens, refresh, and scopes, while enforcing user-specific permissions and auditability.
• Keep tokens completely out of the LLM context; credentials are injected at tool execution only.

Comparison Snapshot:

• Option A: Service Account Bot
  • Single shared identity, broad scopes.
  • Mismatch with real user permissions and compliance policies.
• Option B: DIY OAuth
  • Full control but you own every callback, token store, rotation, and verification.
  • Easy to get wrong; brittle during audits.
• Best for:
  • Use Arcade when you want multi-user agents that act with each user’s Google permissions, with OAuth, token storage, and MCP tools handled for you.

---

How do I actually implement this in my agent or MCP client?

Short Answer: Initialize Arcade in your runtime, trigger auth.start or tools.authorize when the agent needs Google access, then let the agent call Arcade’s Google tools as usual.

Expanded Explanation:
Your agent doesn’t need to know anything about OAuth. It only needs to know that certain tools require authorization and that it may need to show an auth link to the user. Arcade’s MCP runtime handles:

• Mapping user_id to the correct Google credentials.
• Enforcing scopes and permission gates.
• Logging each tool call for audit.

Once a user is connected, your agent moves from “window shopping” to actually sending emails, creating calendar events, or reading threads—within the bounds of that user’s permissions.

What You Need:

• Arcade account & API key
  • Sign up at Arcade, get your key, and install the SDK.
• Google Cloud OAuth client
  • Client ID/secret configured with Arcade’s redirect URI and the least-privilege scopes your tools require.

---

How does this approach help with long-term security and compliance?

Short Answer: Arcade enforces user-specific authorization with scoped OAuth, keeps tokens out of the LLM, and gives you audit trails and governance controls your security team can actually sign off on.

Expanded Explanation:
Most AI agent stacks crumble in a security review because there’s no clear authorization model. With Arcade:

• Each tool call is executed with a real user’s permissions, not a shared bot.
• OAuth tokens are stored and rotated by Arcade; they never pass through prompts or model context.
• You get an audit trail of who did what, where, and when—tied to user IDs and tools (Gmail.ListEmails, Google.SendEmail, etc.).
• Enterprise controls like tenant isolation, RBAC, and SSO/SAML slot into your existing security posture.

This isn’t generic “AI workflow automation.” It’s authorization enforced in code at the runtime layer, which is where security teams expect to see it.

Why It Matters:

• Impact 1: You can ship agents that send emails, manage calendars, and touch real customer data without tripping over security reviews.
• Impact 2: You avoid the refresh-token fire drills and ad-hoc OAuth patches that derail most agent projects at scale.

---

Quick Recap

To configure Google Workspace so each user connects their own account, you: (1) create a Google Cloud OAuth client, (2) register it in Arcade with the right redirect URI and scopes, and (3) call auth.start or tools.authorize for each user when your agent needs access. Arcade takes over from there—managing OAuth redirects, tokens, refreshes, and tool-level authorization—so your agent can safely act in Gmail, Calendar, and other Workspace tools with user-specific permissions.

Next Step

Get Started