An “n8n OAuth token expired” error means your workflow can no longer use the provider’s access token to call an API, so requests that worked yesterday can suddenly fail today unless n8n can refresh the token or you re-authorize the credential.
To solve it reliably, you need to know what actually expired (access token vs refresh token), where the failure surfaces in n8n, and which provider rules (like “Testing” vs “In production”) can force recurring expirations even when your setup looks correct.
Once you identify the real cause, the fix is usually straightforward: correct the OAuth configuration (scopes, offline access, redirect URLs), confirm n8n can store and reuse refresh tokens, and validate refresh behavior with logs instead of guessing.
Introduce a new idea: instead of treating “token expired” as a one-off re-login problem, treat it as a token-lifecycle system you can design, test, and harden—so your automations run for months without surprise re-auth prompts.
What does “n8n OAuth token expired” mean in practice?
It means n8n is holding credentials that no longer authorize API calls—most often an expired access token (short-lived) or an invalid refresh token (long-lived), resulting in errors like invalid_grant or “Token has been expired or revoked.”
To begin, the quickest way to interpret the message is to map it to OAuth token roles and what n8n stores inside the credential.
Access token vs refresh token: which one actually “expired”?
In OAuth 2.0, the access token is what your workflow sends on each API call, while the refresh token (when issued) is what the client uses to obtain a new access token without user interaction.
- If the access token expired, a refresh request should fix it automatically—unless refresh fails.
- If the refresh token is invalid/expired/revoked, automated refresh cannot recover, and you must re-authorize (or change provider-side settings that caused revocation).
Where you’ll see it in n8n workflows
You typically see it as a node execution failure in a node that uses OAuth2 credentials (for example Google nodes, HTTP Request with OAuth2, or custom nodes using OAuth2). n8n will attempt refresh when supported, but the node still fails if refresh is denied or the stored token set is incomplete.
- Some providers return
401/403with “invalid_token” for expired access tokens. - Refresh failures often return
invalid_grant(expired/revoked refresh token, clock issues, or misconfiguration).
Why this can break “healthy” automations without any n8n change
Even if your n8n instance, workflow, and credential didn’t change, token validity can change due to provider policies, user actions (revoking app access), consent screen status, or missing “offline” issuance conditions. That’s why diagnosing which token failed is the first practical step.
Should n8n automatically refresh expired OAuth2 tokens?
Yes—n8n should refresh expired OAuth2 access tokens automatically when a refresh token exists and the provider allows refresh, because it prevents workflow downtime, reduces manual re-auth, and preserves long-running automation reliability.
Then, the key is understanding the boundaries: n8n can refresh access tokens, but it cannot override provider decisions that revoke refresh tokens or refuse to issue them.
Reason 1: Access tokens are designed to expire, refresh is the normal path
OAuth 2.0 explicitly anticipates short-lived access tokens and defines refresh tokens as the mechanism for obtaining new access tokens without re-authentication. In other words, “automatic refresh” isn’t a convenience feature—it’s how OAuth is meant to be operated in production systems.
Reason 2: Manual re-auth is fragile for unattended workflows
If a workflow is expected to run 24/7 (alerts, sync jobs, scheduled reporting), requiring a human to re-login turns a system into a “best effort” process. This is especially damaging for background automations where failures may be silent until business impact appears (missed syncs, incomplete exports, stale dashboards).
Reason 3: Refresh reduces security risk compared to repeated full logins
Refreshing narrowly-scoped tokens is usually safer than repeatedly running full interactive login flows, because it reduces how often users re-enter credentials and limits exposure to phishing-like consent prompts. Also, token leakage has real-world abuse consequences; research measuring OAuth access token abuse in the wild highlights how valuable stolen tokens can be at scale.
When n8n cannot refresh automatically
- No refresh token was ever issued (common when offline access wasn’t requested or the provider only issues refresh tokens under specific conditions).
- Refresh token was revoked/expired by provider policy or user action (for example: “Testing” mode policies that force 7-day refresh token expiration).
- Credential storage/instance mismatch (multiple n8n instances, lost encryption key, or credential data not persisted correctly).
Why do OAuth tokens expire repeatedly in n8n?
OAuth tokens expire repeatedly in n8n because either the provider is never issuing a durable refresh token, the refresh token is being invalidated by policy (like “Testing” mode), or n8n cannot reliably reuse the stored token set across runs—each of which causes recurring “expired” failures.
Specifically, you can isolate the cause by checking whether the failure is an access token expiry (expected) or a refresh token failure (a configuration or policy problem).
Cause 1: Your provider issues refresh tokens that expire every 7 days in “Testing” mode
Some providers (notably Google APIs under certain consent screen settings) can issue refresh tokens that expire after 7 days when the project’s publishing status is Testing. This often shows up as invalid_grant and forces weekly re-authorization.
- If you see a strict 7-day pattern, treat it as a policy signal—not a random bug.
- Fix typically requires changing the OAuth consent screen publishing status to In production (and completing verification steps where required).
Cause 2: Offline access (or equivalent) wasn’t actually granted
Even when your credential “connects,” the provider may only grant an access token without a refresh token unless offline access is requested and consent conditions are met. In n8n, this is common when setting up generic OAuth2 credentials or custom operations: you can authenticate successfully once, but the connection cannot be renewed silently later.
Cause 3: The refresh token was revoked by the user or by security events
If the user revokes app access in the provider’s security settings, rotates passwords, or the provider detects suspicious activity, refresh tokens can be invalidated. n8n will keep trying refresh until it receives an unrecoverable response, then you’ll see token-expired style failures.
Cause 4: Multi-instance n8n or credential persistence problems
If you run multiple n8n instances behind a load balancer, or you changed encryption keys / lost persisted credential data, one instance may not be able to decrypt or access the same token set another instance stored. The result looks like random “token expired” events because the token refresh can’t complete consistently.
Cause 5: Scope changes or provider-side consent resets
When you change scopes (add permissions), many providers require the user to consent again. If the workflow uses a scope that the token set does not cover, the API may fail even if the access token is technically “valid,” and you may misinterpret it as expiration.
How do you fix “token expired” in n8n step by step?
Fixing “token expired” in n8n is a 6-step process: identify whether refresh is failing, confirm the provider consent-screen status and offline issuance, re-authorize to obtain a valid refresh token, verify redirect URLs and scopes, test refresh with a controlled run, and harden persistence so tokens survive restarts.
Below is a practical checklist that works for most OAuth2-backed nodes and the HTTP Request OAuth2 credential.
Step 1: Confirm which credential type you’re using (and where it’s used)
- If you’re using a dedicated provider credential (like Google OAuth2 in n8n), follow the provider-specific n8n docs.
- If you’re using HTTP Request with OAuth2, confirm the token URL, auth URL, scopes, and client credentials match the provider’s expectations.
Step 2: Check for the “7-day Testing mode” pattern (Google and similar platforms)
If failures happen about every 7 days and show invalid_grant, check whether your OAuth project is in Testing status. If it is, move it to In production (and address any verification requirements).
Step 3: Re-authorize the credential to obtain a fresh refresh token
Re-authentication is necessary when the refresh token is invalid or missing. In n8n, open the credential, run “connect”/“sign in” again, and save—then re-run a workflow execution that previously failed.
- If the provider only issues refresh tokens once, you may need to revoke the app access first, then re-consent so the provider issues a new refresh token.
Step 4: Ensure offline access and consistent consent conditions
For providers that require offline access parameters, ensure you are truly requesting offline access and not relying on a one-time interactive session. In n8n, provider-specific credential guides often include the exact OAuth setup steps needed to ensure durable access.
Step 5: Validate redirect URI and environment configuration (especially self-hosted)
- Confirm the provider’s OAuth client has the correct redirect URL configured for your n8n domain.
- If you’re self-hosted behind a reverse proxy, confirm the external base URL matches what the provider sees (scheme + domain + path), otherwise you’ll see intermittent authorization failures that look like token problems.
Step 6: Run a controlled test to verify refresh actually works
Trigger a workflow run that makes multiple API calls over a few minutes, then re-run later after the typical access token lifetime window. If the refresh token works, the second run should succeed without re-login.
- If the run fails with parsing errors, you may be dealing with n8n invalid json payload responses from the API or proxy layer—fixing the OAuth token alone won’t solve a malformed response body.
How do you troubleshoot OAuth token refresh failures in n8n logs?
You troubleshoot OAuth token refresh failures in n8n by enabling verbose logging, reproducing the failure, capturing the provider’s error response (especially invalid_grant), and correlating it with credential configuration (scopes, consent status, redirect URLs) to determine whether the failure is policy-driven, configuration-driven, or storage-driven.
More specifically, effective n8n troubleshooting here means you stop treating the token as a black box and start treating refresh as an observable request/response cycle.
What to look for first: “invalid_grant” and “expired or revoked” signals
If your logs show invalid_grant or “Token has been expired or revoked,” the refresh token is not usable. For Google ecosystems, this frequently correlates with the OAuth consent screen being in Testing mode and issuing refresh tokens that expire after 7 days.
How to separate “token refresh failed” from “API call failed”
- Refresh failure: happens before the API request can be authorized; you’ll see errors around token endpoint responses.
- API failure: you might still have a valid token, but the API returns permission errors, quota errors, or malformed responses.
This distinction matters because a node can fail for reasons that masquerade as token problems. For example, a workflow might appear broken due to n8n pagination missing records when the real issue is that token refresh occurs mid-pagination and the API silently changes page boundaries or enforces stricter rate limits on retries.
Common log patterns and what they mean
401 Unauthorizedimmediately: likely expired access token; refresh should have happened, so investigate why refresh token isn’t present or isn’t used.invalid_grant: refresh token invalid/expired/revoked, clock skew, or client mismatch.redirect_uri_mismatchduring re-auth: OAuth client config mismatch; fix redirect URL in provider console.invalid_scopeor “insufficient scope”: scope set changed; re-consent required.- n8n invalid json payload errors: the HTTP response body is not valid JSON (often an HTML error page from a proxy, WAF, or provider), which can hide the real OAuth error underneath.
A quick diagnostic table you can use during incidents
The table below maps the most common “token expired” failure signals to likely causes and the fastest fix path.
| Symptom in n8n | Likely cause | Fastest fix |
|---|---|---|
invalid_grant after ~7 days |
Provider project in Testing; refresh tokens expire weekly | Switch to In production; re-authorize credential |
| Works once, fails later with 401 | No refresh token issued (offline access not granted) | Adjust OAuth config; re-consent to obtain refresh token |
| Random failures in cluster | Multi-instance storage/encryption mismatch | Align encryption keys + persistence; test sticky sessions |
| Token looks valid but calls fail | Scope/permission mismatch or API-level issues | Re-consent scopes; confirm API enablement and quotas |
How can you prevent weekly or recurring token expirations long-term?
You prevent recurring token expirations long-term by moving OAuth apps to production-grade consent settings, ensuring refresh tokens are issued and stored durably, monitoring refresh failures proactively, and designing workflows with safe retries and idempotent pagination so a refresh event never corrupts results.
Moreover, the goal is not “no expirations” (access tokens should expire), but “no downtime due to expirations.”
Prevention 1: Use production settings for real automations
If you’re running real workflows, treat “Testing” consent screen status as a temporary development state. Documentation for Google’s ecosystem explicitly notes that refresh tokens can expire every 7 days in Testing, which makes it unsuitable for durable automation.
Prevention 2: Make token storage survivable across restarts and upgrades
- Persist n8n data correctly (database volumes, configuration) so credentials and tokens do not reset after container restarts.
- Keep encryption keys stable so existing credentials remain decryptable across deployments.
Prevention 3: Monitor refresh health and alert before failures cascade
Implement a lightweight “credential health check” workflow that runs on a schedule and tests a low-cost API endpoint. If it fails with refresh-related errors, notify you before critical production workflows begin failing.
Prevention 4: Make workflows resilient to token refresh timing
- Use idempotent writes (upserts where possible) so retries don’t create duplicates.
- When paginating, checkpoint progress so a refresh or retry can resume without causing n8n pagination missing records or double-processing pages.
- Handle rate limits explicitly so a refresh-triggered retry doesn’t amplify throttling.
Prevention 5: Treat token lifecycle as a design choice, not an afterthought
Academic work on OAuth token lifecycle highlights that OAuth 2.0 doesn’t mandate a single token format or lifecycle management approach, leaving key lifecycle decisions to integrators—so designing revocation, auditing, and management is part of “doing OAuth well.” According to a study by Athens University of Economics and Business from the Department of Informatics (School of Information Sciences and Technology), in 2020, researchers emphasized that OAuth 2.0 leaves token lifecycle management as an integrator design choice and evaluated token-management operations in measurable cost units (gas) in their proof-of-concept implementation.
What edge cases cause OAuth tokens to expire in n8n even after you “fix” them?
Even after you “fix” the obvious setup, tokens can still appear to expire in n8n due to edge cases like provider-side revocation events, consent/scope drift, multi-user credential mix-ups, cluster routing issues, or workflow patterns (pagination, retries, parsing) that mask the real failure as an “expired token” problem.
In addition, these edge cases are where teams often waste the most time—because the UI shows “connected,” yet execution still fails.
Edge case 1: The refresh token exists, but the provider silently revoked it
Providers may revoke refresh tokens when security settings change, when an app is reconfigured, or when users revoke access. The symptom looks like a normal expiry, but the fix is always re-consent (and sometimes restoring provider-side settings such as production publishing status).
Edge case 2: Credential “works” for one user but fails for another (shared workflows)
When multiple users trigger the same workflow but share a single OAuth credential, the token represents one identity. If you intended per-user identity, you need a different architecture (separate credentials per user or a delegated model). Otherwise, you’ll see sporadic authorization failures that look like token expiry but are actually identity mismatch.
Edge case 3: Scopes changed after the credential was created
If you add scopes in the provider console or change the node’s required scopes, the existing refresh token may not automatically gain new permissions. The workflow fails, and users interpret it as “token expired” because re-auth fixes it—temporarily—until the next scope drift event.
Edge case 4: Reverse proxy or base URL mismatch causes partial OAuth failures
In self-hosted setups, a subtle scheme/domain mismatch (HTTP vs HTTPS, internal host vs public host) can make OAuth callbacks inconsistent. You may successfully connect once, but future refresh or re-auth attempts fail. This is especially common when environments change (new domain, new proxy, new path prefix).
Edge case 5: The real failure is response handling, not OAuth
Sometimes “token expired” is the first visible error, but the deeper issue is workflow reliability: malformed responses (n8n invalid json payload), unexpected HTML error pages, or pagination logic that causes n8n pagination missing records. In these cases, you should fix OAuth and make the workflow resilient to retries, partial failures, and API quirks—otherwise the same incident pattern returns under load.
Evidence (if any): For baseline definitions of access tokens and refresh tokens and how OAuth 2.0 is intended to work, refer to IETF RFC 6749. For the specific recurring 7-day refresh token expiration pattern tied to “Testing” status in Google projects, see Google Developers documented invalid_grant handling guidance. For n8n-specific credential setup and troubleshooting steps for Google OAuth2 in n8n, see n8n Docs.