OAuth Token Expiry: How to Never Lose a Client Connection Again in Your Automation Workflows

At some point in every automation builder's career, a client sends a message that goes something like this: "Hey, the reports haven't come in for three days. Everything okay?"

You check the workflow. It failed at 2:47 AM on Tuesday. The error message reads something like 401 Unauthorized or invalid_grant or, cryptically, just "Request failed." The cause, when you dig into it, is always the same: an OAuth token expired, and nobody caught it.

This scenario costs automation agencies real money, real client trust, and real time. Multiply it across fifty client connections - each with its own Google, Microsoft, or Slack authorization - and the odds of at least one failing silently at any given moment approach certainty.

This guide explains how OAuth tokens actually work, why they expire in ways that break automation workflows, how different providers handle expiry differently, and - most importantly - how to build a system that catches token failures before clients feel them.

OAuth Fundamentals: Access Tokens, Refresh Tokens, and Why Both Matter

OAuth 2.0 is the authorization framework used by virtually every major API provider: Google, Microsoft, Slack, Salesforce, GitHub, Dropbox, and hundreds of others. Understanding how it works at a mechanical level is essential for any automation builder who manages connections on behalf of clients.

The Two Token Types

When a user authorizes your application to access their account (by clicking "Allow" on an OAuth consent screen), the authorization server issues two tokens:

Access tokens are short-lived credentials that prove your application has permission to make API calls on the user's behalf. They are included in the Authorization: Bearer header of API requests. They are the "key" that opens the door to the API.

Refresh tokens are long-lived credentials used exclusively to obtain new access tokens when old ones expire. Refresh tokens are not sent with API calls - they are stored securely and used only when communicating with the authorization server's token endpoint to request a fresh access token.

The Token Lifecycle in Automation

In a correctly functioning automation workflow:

The user authorizes your app → authorization server issues an access token (short-lived) and a refresh token (long-lived).
Your automation stores both tokens securely.
Your workflow makes API calls using the access token.
When the access token expires (typically after one hour), your automation uses the refresh token to request a new access token.
The authorization server returns a new access token (and sometimes a new refresh token).
Your automation stores the new tokens and continues making API calls.

In a correctly functioning system, this cycle repeats indefinitely. The user authorizes once, and the automation continues working - refreshing its access tokens transparently - for months or years.

In a broken system - the one most automation agencies are inadvertently running - step 4 either does not happen automatically, or it fails silently. The workflow gets a 401 error and stops. Nobody is notified. The client's automation is dead.

What Happens in n8n When a Token Expires

n8n stores OAuth credentials in its credential vault. When you create a Google Sheets credential, n8n stores the access token and refresh token. n8n's native OAuth nodes handle token refresh automatically - in theory.

In practice, token expiry in n8n manifests in several ways:

Silent Workflow Failure

The most common scenario: a workflow executes, makes a Google API call, receives a 401 Unauthorized response, and the workflow execution fails. If you have no error handling set up, n8n logs the failure internally but sends no notification. The failure is visible in the execution history, but only if you look for it.

Client impact: The automation stops producing results. Reports stop arriving. Data stops syncing. The client notices eventually - often days later.

The "Stuck Refresh Token" Problem

In some cases, n8n's credential system has difficulty refreshing certain OAuth tokens, particularly when:

The user changed their password after authorizing the app (which can invalidate all existing tokens)
The user revoked the app's access in their Google account settings
The authorization scopes were changed after initial authorization
Google or Microsoft issued a new set of tokens but the credential node did not update correctly

When a refresh fails, n8n typically marks the credential as needing re-authorization. But if the workflow is unattended (as most automated workflows are), no one re-authorizes it until a client notices the failure.

Cascade Failures

In multi-client agency setups where one credential is shared across related workflows, a single token expiry can cascade to multiple workflow failures simultaneously. One refresh failure means every workflow using that credential fails. If that client has five related automations, all five stop at once.

Google OAuth Token Specifics

Google's OAuth implementation is among the most widely used and the most commonly encountered in automation workflows connecting to Google Workspace (Gmail, Google Sheets, Google Drive, Google Calendar, Google Docs).

Access Token Lifetime: 1 Hour

Google's access tokens expire after exactly 3,600 seconds (one hour) from issuance. This is not configurable. Every Google API call made more than one hour after the access token was issued will receive a 401 error unless the access token has been refreshed.

For automation workflows that run frequently (every few minutes or every hour), token refresh needs to be reliable and automated. For workflows that run daily or weekly, the access token will always be expired by the time the workflow runs - making token refresh not just helpful but mandatory.

Refresh Token Validity: Variable but Long

Google refresh tokens do not have a fixed expiry time, but they can become invalid in several circumstances:

If the user revokes access in their Google account's security settings (myaccount.google.com/security), the refresh token is immediately invalidated.
If the app's OAuth consent has not been verified, Google may expire refresh tokens after seven days for apps in testing mode. Production-verified apps do not have this limitation.
If the user does not use the app for six months, Google may expire the refresh token (this applies to certain consumer account scenarios).
If the user changes their Google account password, refresh tokens may be invalidated (behavior varies by account type and configuration).
Refresh tokens can also be invalidated if you request a new refresh token - by default, Google OAuth only issues a fresh refresh token when the user re-authorizes with access_type=offline&prompt=consent.

Practical Implication for Automation Agencies

Every Google connection your agency manages will eventually require re-authorization - either because a client's refresh token expires, or because the client changes their password, or because they accidentally revoke access. Your system needs to detect this promptly, alert you, and make it easy to re-authorize.

Without an alert system, you discover the problem when the client asks why their reports stopped.

Microsoft OAuth Token Specifics

Microsoft's OAuth implementation (used for Microsoft 365 services: Outlook, SharePoint, OneDrive, Teams, Azure AD) differs from Google's in several important ways.

Access Token Lifetime: 60-90 Minutes

Microsoft access tokens default to 60 minutes but Microsoft's token service uses Continuous Access Evaluation (CAE) in some configurations, which can extend the effective lifetime to up to 28 hours for compliant clients. For most automation builders, the practical lifetime to plan for is 60 minutes.

Refresh Token Lifetime: 90 Days (Rolling)

Microsoft refresh tokens have a much more explicit expiry policy than Google. By default:

Refresh tokens for Microsoft accounts (personal) expire after 90 days of inactivity.
The 90-day clock resets every time the refresh token is used. If your workflow runs at least once every 90 days, the refresh token effectively never expires.
For Azure AD (enterprise accounts), administrators can configure token lifetimes. Some organizations configure shorter refresh token lifetimes (as short as 10 minutes) or disable refresh tokens entirely for certain security policies.
Conditional Access policies can force re-authentication regardless of token freshness. If a client's IT department enables a Conditional Access policy that requires multi-factor authentication for all sessions, automation service accounts may be blocked.

The Service Account Recommendation

For Microsoft integrations in automation contexts, the recommended approach is to use a dedicated service account (a Microsoft 365 account created specifically for automation, not a person's account). This isolates the automation's credentials from individual user behavior and makes it less likely that a password change or MFA requirement breaks the workflow.

Azure AD App Permissions vs Delegated Permissions

Microsoft distinguishes between:

Delegated permissions: The app acts on behalf of a signed-in user. Requires the user to be present for initial authorization and is subject to that user's access controls.
Application permissions: The app acts with its own identity, without a signed-in user. Used for background services and automation. Requires admin consent.

For automation agency use cases where workflows run unattended on behalf of a client organization, Application permissions with client credential flow (client ID + client secret, no user involvement after initial setup) can be more robust than delegated permissions. However, they require the client's Microsoft 365 administrator to grant consent, which adds friction to onboarding.

Slack Token Specifics

Slack tokens behave quite differently from Google and Microsoft tokens, and understanding this difference prevents a common misconception.

User Tokens and Bot Tokens

Slack issues two main token types for app integrations:

User tokens (xoxp-...): Represent a specific user's authorization. The token acts as that user within the workspace.
Bot tokens (xoxb-...): Represent the app/bot itself within a workspace. Issued when the app is installed to a workspace.

For automation workflows, bot tokens are almost always the correct choice. They represent the app's presence in the workspace rather than a specific user's session.

Workspace Tokens Do Not Have Standard Expiry

Unlike Google and Microsoft, Slack bot tokens and user tokens do not have a time-based expiry. A token issued when an app is installed in a workspace remains valid indefinitely - as long as:

The app has not been uninstalled from the workspace
The token has not been manually revoked by the workspace administrator
The Slack app itself has not been suspended or deleted

This makes Slack integrations significantly simpler to maintain from a token management perspective. You do not need an automatic refresh mechanism for Slack tokens.

What Can Invalidate a Slack Token

Even though Slack tokens do not expire on a schedule, they can become invalid when:

A workspace administrator uninstalls the app - the bot token is revoked immediately
A workspace administrator explicitly revokes the token via Slack's admin tools
The app is deactivated by Slack for violating terms of service
Enterprise Grid organizations may rotate tokens during security audits or ownership transfers

For automation agency purposes: Slack connections are lower maintenance than Google or Microsoft, but you still need a way to detect when a token is revoked - because the client's workflow will fail silently until you catch it.

Strategies to Handle Token Expiry

Strategy 1: Manual Refresh (The Status Quo)

Most automation builders start here by default: when a workflow fails with a 401 error, someone investigates, identifies the expired token, re-authorizes the connection, and restarts the workflow.

Problems:

Detection is entirely reactive - you find out after the client reports an issue.
The re-authorization process typically requires the client to be available (to re-grant access to their account).
At scale, this becomes a constant firefighting exercise.

This strategy is acceptable for one or two workflows. It is untenable at agency scale.

Strategy 2: Scheduled Refresh Jobs

A proactive approach: build a dedicated workflow that runs on a schedule (say, every 50 minutes) with the sole purpose of refreshing all OAuth tokens before they expire. The workflow calls the token endpoint for each stored token, exchanges the refresh token for a new access token, and stores the new access token for use by subsequent workflow executions.

Problems:

Requires custom infrastructure to store and manage tokens separately from n8n's built-in credential system.
Building a robust token refresh workflow is non-trivial - you need to handle edge cases (refresh token revocation, rate limiting, concurrent refresh attempts).
Does not handle Microsoft Conditional Access failures or Slack token revocations gracefully.
Duplicates work that a proper token management system should handle transparently.

This is the "build your own CredBridge" approach. Some technically sophisticated agencies go this route. Most find that maintaining the refresh infrastructure is a project in itself.

Strategy 3: Automatic Refresh with Expiry Monitoring (The Right Architecture)

The best architecture separates concerns cleanly:

Token storage is handled by a dedicated, secure vault - not n8n's credential system.
Token refresh happens transparently at the vault layer, before tokens are returned to workflows.
Refresh failure detection triggers immediate alerts to the agency, not silent workflow failures.
Workflows remain simple - they request a token, receive a valid one, and proceed.

This is exactly the architecture CredBridge implements. Every token retrieval request is evaluated for freshness. If the access token is expired or about to expire, CredBridge uses the stored refresh token to fetch a new one from the provider's token endpoint before returning the access token. The workflow always receives a valid token. Expiry is never the workflow's problem.

The CredBridge Approach: Transparent Auto-Refresh and Failure Alerts

CredBridge handles the complete OAuth token lifecycle for automation agencies:

Transparent Auto-Refresh

When your n8n workflow (or Make scenario) calls the CredBridge token API, CredBridge checks the stored access token's expiry timestamp. If the token expires within the next five minutes, or has already expired, CredBridge:

Fetches the stored refresh token for that tenant
Makes a POST request to the provider's token endpoint (Google, Microsoft, or Slack)
Receives the new access token (and refresh token, if one is issued)
Stores the new tokens securely
Returns the fresh access token to your workflow

This happens in milliseconds, transparently. Your workflow receives a valid access token every time, without knowing or caring whether a refresh happened behind the scenes.

Email Alerts on Refresh Failure

If the refresh itself fails - because the user revoked access, the refresh token expired, the user changed their password, or a Conditional Access policy blocked the request - CredBridge immediately sends an email alert to the agency with:

Which tenant (client) is affected
Which service (Google, Microsoft, or Slack)
The specific error returned by the authorization server
A link to generate a new OAuth authorization URL to send to the client

This means the agency knows about a broken client connection within minutes of it breaking - not days later, when the client notices.

The Workflow Experience

From the workflow's perspective, every CredBridge interaction is a single HTTP GET request. There is no token expiry logic in the workflow, no refresh handling, no conditional branches for auth failures. The workflow is simple, readable, and maintainable.

GET https://api.credbridge.io/token?client_id=CLIENT_ID
Headers:
  Authorization: Bearer YOUR_CREDBRIDGE_API_KEY

Response:
{
  "access_token": "ya29.a0AfH...",
  "token_type": "Bearer",
  "expires_in": 3599
}

Your workflow uses access_token in the Authorization header of every subsequent API call. Token management is entirely off the workflow's critical path.

Best Practices for Secure Token Storage

Whether you use CredBridge or build your own token management infrastructure, these practices are non-negotiable for any agency handling client OAuth tokens.

Encryption at Rest

OAuth tokens must be encrypted at rest. Storing plaintext access tokens or refresh tokens in a database without encryption means that a database compromise exposes all your clients' account access simultaneously. Use AES-256 encryption (or equivalent) for all token storage. The encryption key must be stored separately from the encrypted data - ideally in a dedicated secret management service like AWS Secrets Manager, HashiCorp Vault, or a similar tool.

CredBridge encrypts all tokens at rest using AES-256 encryption with keys managed separately from the token store.

Never Log Tokens

Access tokens and refresh tokens must never appear in application logs. This means:

No console.log or logger.info that includes request/response bodies containing tokens
HTTP request logging must be configured to redact Authorization headers
Error messages must not include the token that caused the error

Logs are often stored in less secure locations than application databases, are frequently shared for debugging, and may be retained for months or years. A token that appears in a log file is effectively public within your organization.

Use HTTPS Exclusively

All communication with token endpoints and token APIs must use HTTPS. Never transmit tokens over HTTP connections. Modern APIs enforce this at the server level, but ensure your own infrastructure - particularly any internal APIs or token proxy services - also requires TLS.

Rotate Service Account Credentials Periodically

For any service accounts (Google service accounts, Azure service principals) you use in addition to user OAuth, rotate the credentials (client secrets) on a regular schedule - at minimum annually, ideally quarterly. Build this into your operational calendar so it does not get missed.

Scope Minimization

When requesting OAuth authorization from clients, request only the scopes your automation actually needs. If your workflow reads Google Sheets data, request https://www.googleapis.com/auth/spreadsheets.readonly rather than the full spreadsheets scope. Minimizing scopes reduces the blast radius of a compromised token and increases client trust during the authorization consent screen.

Monitor for Unauthorized Access

If a client reports suspicious activity in their Google, Microsoft, or Slack account, the OAuth authorization your automation holds should be your first thing to check. A security incident review process should include: listing all active authorizations, revoking any that are no longer needed, and re-authorizing only the scopes still required.

Building a Token Health Dashboard

For agencies managing many clients, a token health view is essential for proactive maintenance. At minimum, you should be able to see:

Which clients have active, healthy OAuth connections
When each connection's refresh token was last successfully used
Any connections that have not been used recently (and may be at risk of expiry)
Any connections where a refresh failure was detected

CredBridge's dashboard provides this visibility across all your tenants. You see at a glance which clients are healthy, which have recent warnings, and which require re-authorization. This transforms token management from a reactive firefighting task into a routine maintenance item.

The True Cost of Token Expiry Failures

Token expiry failures are not just a technical nuisance - they have real business consequences for automation agencies:

Client trust: A client whose automation stops working unexpectedly loses confidence in the service. If it happens more than once, they begin to wonder whether the value they are paying for is real.

Emergency support time: Debugging a token expiry failure, identifying which credential expired, contacting the client, waiting for them to re-authorize, testing the fix - this process easily takes one to two hours per incident. At agency scale, these incidents happen monthly or weekly.

Churn risk: Clients who experience repeated, unexplained failures churn. They may not explicitly cite "the Google token expired again" as the reason, but silent failures that produce gaps in reports or broken workflows are one of the most common causes of automation agency churn.

Reputation: In a market driven by referrals, one client who tells a peer "their automations kept breaking" is more damaging than a month of marketing spend can fix.

The investment in proper token management infrastructure - estimated at $49/month for fifty clients with CredBridge - is trivially small compared to the cost of even one monthly token-expiry incident requiring emergency client communication and re-authorization.

Never Lose a Client Connection Again

OAuth token expiry is a solvable problem. The solution requires understanding the token lifecycle, building infrastructure that handles refresh transparently, and alerting the right people when refresh fails.

CredBridge handles all three:

Transparent auto-refresh for Google (1-hour access tokens), Microsoft (60-minute access tokens), and Slack (event-driven revocation detection)
Immediate email alerts when a token cannot be refreshed, with context on the cause and a link to re-authorize
Encrypted token storage with AES-256, keeping client credentials secure at rest
A health dashboard showing the status of all your tenant connections at a glance
Simple API integration for both n8n and Make - one HTTP call per workflow execution, always a valid token in return

Your clients authorized you once. They trusted you to keep their automations running. CredBridge makes sure that trust is never broken by a silent token expiry in the middle of the night.

Plans:

Solo - $19/month - Up to 10 client tenants. OAuth token management for growing automation businesses.
Agency - $49/month - Up to 50 client tenants. Enterprise-grade token management for professional multi-client agencies.

Stop chasing expired tokens. Start with CredBridge.