Google OAuth 2.0: set it up for API automation

Google OAuth 2.0 is the gatekeeper to every Google API that touches user data — Gmail, Drive, Calendar, YouTube, Sheets. You can't automate anything meaningful with Google services without going through OAuth first. OAuth-related configuration errors are the number one support ticket category for the Google Cloud API team. CodeWords simplifies this by managing token storage and refresh inside your workflow automation, so you authenticate once and your automation runs indefinitely.

How Google OAuth 2.0 works

Think of OAuth 2.0 as a valet key system. You issue a valet key that only opens specific doors (scopes) and expires after a set time (access token lifetime). The four-step flow: (1) Your app requests authorization via redirect to Google's consent screen with specific scopes, (2) User grants permission; Google returns an authorization code, (3) App exchanges code for access token (1 hour) + refresh token (long-lived), (4) App uses access token for API calls; uses refresh token to get new access tokens when they expire.

Setup: creating credentials

Step 1: Create a GCP project specifically for your automation. Step 2: Enable required APIs (Gmail, Drive, Sheets, Calendar, YouTube Data API v3). Only enable what you need. Step 3: Configure OAuth consent screen — choose External (general use), fill in app name, user support email, developer contact, and add minimum required scopes. Step 4: Create OAuth client ID — Desktop application for local scripts, Web application for server workflows (set redirect URI). Download client_secret.json. Never commit this to version control.

Service accounts vs OAuth client IDs

Service accounts are for server-to-server automation where no human user is involved. Ideal for processing shared Google Sheets, managing team Drive folders, or accessing GCP services. Service accounts have their own email address; to access a user's Sheet, that user must share it with the service account email. Key difference: OAuth client IDs act on behalf of a user (requires consent); service accounts act as their own identity (no consent needed, but files must be shared).

Managing tokens in CodeWords

Inside CodeWords, OAuth tokens persist across workflow runs using Redis-based state management. Tokens are stored encrypted, refreshed proactively before expiration, and injected at runtime into your ephemeral E2B sandboxes — they never appear in your code or logs. Multiple workflows share the same Google connection without each developer managing their own token files.

Common errors and fixes

• redirect_uri_mismatch: Add the exact URI from the error message to Authorized Redirect URIs in Cloud Console
• access_denied: Add the user's email under OAuth consent screen → Test users
• invalid_grant: Refresh token revoked (user changed password, removed access, or token unused for 6 months) — re-run the consent flow
• insufficient_scope: Add the missing scope and re-authorize

Set up your Google API automation in CodeWords — authenticate once, automate everything →