OAuth 2.0 flow explained

OAuth 2.0 is an authorization framework that lets a third-party application access a user's resources on another service without handling their password. When you click "Connect with Google" in an app and grant access to your calendar, OAuth 2.0 is the protocol making that handshake happen securely.

The framework defines several flows (grant types), each designed for a different scenario — server-side web apps, single-page apps, machine-to-machine communication, and mobile applications. Picking the wrong flow is one of the most common integration mistakes developers make. Unlike generic AI automation posts, this guide shows real CodeWords workflows — not just theory.

The OAuth 2.0 specification (RFC 6749) was published by the IETF in 2012 and remains the dominant authorization standard. According to Okta's 2025 Businesses at Work report, over 95% of enterprise SaaS integrations rely on OAuth 2.0 or its extensions.

Related: Google OAuth 2.0, Google OAuth API, API authentication methods explained, Slack OAuth, Google service account, CodeWords integrations, CodeWords templates.

The four roles in OAuth 2.0

Every OAuth flow involves four participants.

Resource owner — the user who owns the data (you, granting access to your Google Drive).

Client — the application requesting access (your automation platform, like CodeWords).

Authorization server — the service that authenticates the user and issues tokens (Google's OAuth server).

Resource server — the API that holds the protected data (Google Drive API).

The flow's job is to get the client a token from the authorization server, without the client ever seeing the resource owner's password.

Authorization code flow (most common)

This is the standard flow for server-side applications and the one most automation platforms use.

1. The client redirects the user to the authorization server with a request specifying the desired permissions (scopes).
2. The user authenticates and approves the requested permissions.
3. The authorization server redirects back to the client with a short-lived authorization code.
4. The client exchanges the authorization code (plus its own client secret) for an access token and a refresh token.
5. The client uses the access token to call the resource server's API.

The authorization code is a one-time intermediary — it prevents the access token from being exposed in the browser's URL bar. The client secret in step 4 proves the client's identity, adding a second layer of verification.

CodeWords handles this entire flow transparently for its 500+ integrations. When you connect a Google, Slack, or HubSpot account, CodeWords manages the OAuth handshake, stores tokens securely, and refreshes them automatically. No token juggling in your workflow code.

Client credentials flow (machine-to-machine)

When there's no user involved — a server talking to another server — the client credentials flow skips the browser redirect entirely. The client sends its client ID and client secret directly to the authorization server and receives an access token.

This flow is common for backend services, cron jobs, and automated pipelines. Google service accounts use a variant of this flow with JWT assertions instead of client secrets. If your CodeWords workflow accesses a Google Sheets API on a schedule without user interaction, client credentials (or service account auth) is the appropriate flow.

Token refresh and lifecycle

Access tokens expire — typically after 1 hour. The refresh token, issued alongside the access token, is longer-lived and lets the client obtain a new access token without requiring the user to re-authorize.

Token refresh is where automation platforms either shine or break. A workflow that runs daily needs to refresh tokens automatically. If the platform doesn't handle refresh gracefully, workflows fail silently when tokens expire. Zapier and Make handle refresh for their built-in connections. n8n supports refresh but requires more manual configuration for custom OAuth apps.

CodeWords manages the full token lifecycle — initial authorization, secure storage, automatic refresh, and re-authorization prompts when refresh tokens themselves expire (which happens with some providers like Microsoft after 90 days of inactivity).

OAuth 2.0 in automation workflows

Here's where OAuth matters most for builders:

Multi-service workflows. A lead enrichment pipeline might call Google APIs (OAuth 2.0), Slack API (OAuth 2.0), and HubSpot API (OAuth 2.0) in a single execution. Each service has its own token. The automation platform needs to manage three separate OAuth sessions simultaneously.

Scheduled workflows. A monthly report workflow that pulls data from Google Sheets and Salesforce needs valid tokens at execution time. If either token expired and the refresh failed, the entire workflow fails.

Webhook receivers. When your workflow receives a webhook from Stripe or GitHub, it may need to call back to that service's API to fetch additional data — which requires a valid OAuth token ready to use.

Common OAuth mistakes in automation

Storing tokens in plain text. Tokens are credentials. Treat them like passwords. CodeWords encrypts stored tokens and runs workflows in ephemeral E2B sandboxes that are destroyed after execution.

Ignoring scope creep. Request only the permissions your workflow needs. An automation that reads Google Calendar events doesn't need write access to Google Drive.

Not handling token revocation. Users can revoke access at any time. Your workflow needs to detect revocation (usually a 401 response) and prompt for re-authorization rather than failing silently.

Build secure integrations at codewords.agemo.ai — OAuth is handled for you across every supported service.