Fix OAuth Refresh Token Issues in n8n

I’ve had n8n automations fail overnight because a refresh token silently stopped working, so I now treat token health like uptime monitoring.

Fix OAuth Refresh Token Issues in n8n by identifying the exact failure mode, rotating credentials safely, and hardening your OAuth setup so it renews reliably.

What a refresh token failure looks like in real n8n workflows

When refresh token renewal breaks, your workflow usually starts failing only after the access token expires. In n8n, that often shows up as one of these patterns:

Intermittent auth errors that “fix themselves” right after you re-connect, then return hours later.
401/403 responses from the target API after previously successful runs.
Workflows failing only in production (Cron/trigger) while manual executions sometimes work because you recently authenticated.
Errors that mention invalid_grant, unauthorized_client, invalid_client, or invalid_scope.

Your goal is to determine whether the refresh token is missing, revoked, expired by policy, blocked by app settings, or being rejected due to mismatch (client ID/secret, redirect URL, tenant/app mode).

Quick diagnosis checklist (fastest path to the root cause)

Confirm which credential type you used: OAuth2 (generic) vs a built-in app credential (Google/Microsoft/Slack/etc.).
Check if the account password changed or security settings were tightened (common cause of token revocation).
Confirm you didn’t rotate the client secret in the provider without updating n8n credentials.
Look for multi-environment mismatch: Using one OAuth app across dev/staging/prod but different n8n base URLs or redirect URLs.
Verify scopes were not edited after initial consent; changing scopes often requires a fresh consent flow.
Confirm time sync on your server/container; severe clock drift can break OAuth flows or validation.

The most common causes and how to fix each one

1) The refresh token was revoked by the provider or user

This is the #1 cause in real systems: the user removes app access, security policies revoke old tokens, or the provider invalidates tokens after sensitive account changes.

Fix: Re-authenticate from scratch and ensure the provider grants a refresh token again. In n8n, open the credential, run the connect/authorize flow, and save. If you rely on service accounts or admin-consented apps, confirm the admin consent still stands.

Real drawback: Re-auth “fixes” it, but it often breaks again if the underlying policy still revokes tokens (see the prevention section below).

2) Your OAuth app is missing “offline access” behavior

Some providers only issue refresh tokens when you explicitly request offline access or when the app is configured to allow long-lived refresh. Without that, n8n may only receive short-lived access tokens.

Fix: For Microsoft identity flows, ensure you request offline_access where applicable and that the app configuration allows it. For other providers, verify the equivalent setting exists and is enabled.

Real drawback: Adding offline access usually forces a fresh consent prompt; users may hesitate if your scopes are broader than necessary.

3) Redirect URL mismatch (especially after domain changes or reverse proxies)

If your n8n public URL changed (new domain, Cloudflare tunnel, reverse proxy, different protocol), the redirect URL registered in the provider can become stale, and subsequent refresh flows or re-auth can fail.

Fix: Ensure the provider’s redirect/callback URL exactly matches the URL used by your n8n instance. If you use a reverse proxy, make sure n8n is configured with the correct public URL so it generates consistent callbacks.

Real drawback: Mixing multiple environments with a single OAuth app can cause accidental breakage when one environment’s callback is edited.

4) Client secret rotation happened, but n8n still uses the old secret

Rotating secrets is good security hygiene, but it’s also a common reason refresh calls start failing immediately.

Fix: Update the client secret in the n8n credential and re-test by running a node that forces an API call. If the provider supports multiple active secrets, keep the old one valid temporarily during your cutover.

Real drawback: If you rotate secrets without a controlled rollout, you can break critical automations with no warning.

5) Scope drift: you edited scopes after initial consent

If scopes were changed in your OAuth app or in the n8n credential after the user already consented, the provider may reject refresh or require a new authorization grant.

Fix: Re-authenticate so the user consents to the current scopes. If possible, reduce scopes to the minimum you need—this increases approval rates and reduces security review friction.

Real drawback: Over-scoping increases the chance security teams revoke access later.

6) Provider refresh-token policies (expiration, inactivity limits, rotation)

Many providers enforce refresh token expiration or inactivity limits, and some rotate refresh tokens. If your workflow doesn’t run for a while, the refresh token can become invalid.

Fix: If the provider enforces refresh expiration, schedule a lightweight “keep-alive” workflow that runs periodically and calls a safe endpoint. If the provider uses refresh token rotation, confirm your integration stores the latest refresh token properly; n8n typically handles this, but it can fail if credentials are duplicated incorrectly or overwritten.

Real drawback: Keep-alives add background traffic and must be designed to avoid rate limits.

Provider-specific fixes that matter in the U.S. market

Microsoft Entra ID (Azure AD) OAuth issues

Microsoft OAuth failures often come from tenant settings, admin consent, or missing offline access.

Confirm app registration settings (supported account types, redirect URL correctness, API permissions, and consent).
Verify token configuration and policies in your tenant that may limit refresh usage or require re-auth.
Re-consent after permission changes and ensure the account used for the workflow still has access.

Official portal for app registration and settings: Microsoft Entra admin center

Real drawback: Enterprise tenants can enforce Conditional Access that breaks unattended refresh in ways that look random unless you check policy logs.

Google OAuth issues (Workspace and consumer accounts)

Google refresh behavior is usually tied to consent configuration and app verification posture, especially in Workspace environments.

Check if the user removed access in their Google Account security settings.
Confirm the OAuth consent screen and scopes still match what you request.
Be careful with multiple n8n environments using one Google OAuth app; redirect URLs must be exact.

Official Google Cloud Console (OAuth consent and credentials): Google Cloud Console

Real drawback: If your app triggers verification requirements (sensitive scopes), users may lose trust or admins may block the app across the org.

GitHub, Slack, and other SaaS providers

Most SaaS providers fail in predictable ways: revoked grants, secret rotation, or redirect URL mismatch.

Reinstall/re-authorize the app when a grant is revoked.
Match redirect URLs after any domain/proxy change.
Confirm workspace/org policies didn’t block your app.

Official n8n docs for credential setup and troubleshooting patterns: n8n Documentation

Real drawback: Some providers throttle token refresh or require re-auth after inactivity; your workflows can fail only on “quiet weeks.”

Hardening n8n so refresh token failures don’t surprise you

Add a “token health check” workflow

Create a simple scheduled workflow that calls the same integration once per day (or per business day) using a safe endpoint. Keep it lightweight: one node, one request, and a clear failure alert.

Real drawback: A health check can mask deeper issues if it re-authenticates manually; avoid manual “quick fixes” that hide the root cause.

Standardize environment URLs and redirects

If you have dev/staging/prod, give each environment its own OAuth app credentials whenever possible. This prevents redirect edits in one environment from breaking another.

Real drawback: Managing multiple OAuth apps adds admin overhead, but it dramatically reduces breakage risk.

Use least-privilege scopes

Ask only for scopes you need. This reduces the chance an IT admin revokes access, speeds up security review, and makes re-consent less painful.

Real drawback: Too few scopes can break features later; treat scope updates as a versioned change with a controlled re-consent rollout.

Step-by-step: a safe credential rotation process in n8n

Duplicate the credential so you can test without breaking production nodes immediately.
Re-authorize the duplicate credential (fresh consent) and save it.
Test a single workflow or a single node execution using the new credential.
Swap credentials gradually across workflows, starting with low-risk automations.
Monitor failures for 24 hours, then remove or archive the old credential.

Real drawback: If you rotate everything at once, diagnosing which integration broke becomes slower and more stressful.

Common error messages and what they usually mean

Error snippet	Likely cause	Best fix
invalid_grant	Refresh token revoked/expired, scope drift, or account policy change	Re-auth with correct scopes; check tenant/account security policies
unauthorized_client	Wrong client ID/secret, app misconfigured, unsupported account type	Verify app registration; update secret; confirm account type settings
invalid_scope	Scopes changed or not allowed for the app	Reduce/adjust scopes and re-consent
401 Unauthorized after hours	Access token expires and refresh fails	Fix refresh flow; re-auth; ensure offline access behavior is correct

FAQ: deeper fixes for stubborn refresh token failures

Why does OAuth work in manual runs but fail on scheduled runs?

Manual runs often happen right after you authenticated, while scheduled runs hit the moment your access token expires. Fix the underlying refresh failure (revocation, secret mismatch, redirect mismatch), then validate with a schedule that runs after the token lifetime window.

How do you prevent refresh tokens from expiring due to inactivity?

Run a lightweight workflow regularly that makes a safe API call using the same credential. If the provider has strict refresh expiration regardless of activity, plan for periodic re-consent as an operational task and keep scopes minimal to reduce friction.

Is it safe to reuse one OAuth app for dev, staging, and production?

It works until it doesn’t. If you can, separate apps per environment so redirect URL changes don’t break production. If you must reuse one app, lock down redirect URL changes and document the exact n8n public URL for each environment.

What should you do if an enterprise tenant’s Conditional Access breaks refresh tokens?

Work with the tenant admin to identify the policy blocking unattended token refresh. In many orgs, the fix is an approved app, admin consent, or an exception for service-to-service patterns that don’t rely on interactive sign-in each time.

Do duplicated n8n credentials cause refresh rotation problems?

They can. If a provider rotates refresh tokens and two workflows race using different stored refresh values, you may see intermittent invalid_grant failures. Keep one canonical credential per integration and avoid copying secrets between multiple credentials unless you’re doing a controlled migration.

Conclusion

If your automations matter, treat OAuth refresh like infrastructure: standardize redirects, minimize scopes, rotate credentials safely, and add a simple health check so failures show up before your critical workflows do.

Toolient