invalid_grant: token has been expired or revoked

Not specified by the original author.

TL;DR

For "google.auth.exceptions.RefreshError: ('invalid_grant: Bad Request', ...)": for key files: the key was deleted from the service account, or the SA was deleted/disabled. Check the ADC file timestamp; ancient files from old machine images are suspect. - Key file: gcloud iam service-accounts keys list --iam-account [SA-EMAIL] - is your key ID still there?

google.auth.exceptions.RefreshError: ('invalid_grant: Bad Request', ...)

Steps

1. Symptom: google.auth.exceptions.RefreshError: ('invalid_grant: Bad Request', ...) or "Token has been expired or revoked."
2. Cause: the refresh token ADC is holding is no longer valid. For user credentials: revoked in account settings, expired from disuse, or admin-revoked. For key files: the key was deleted from the service account, or the SA was deleted/disabled.
3. Confirm:

• User ADC: gcloud auth application-default print-access-token fails the same way. Check the ADC file timestamp; ancient files from old machine images are suspect.
• Key file: gcloud iam service-accounts keys list --iam-account [SA-EMAIL] - is your key ID still there? Is the SA itself still enabled?

4. Fix:

• User ADC: delete the stale applicationdefaultcredentials.json and run gcloud auth application-default login fresh.
• Key file: if the key was deleted, create a new one (or better, move to Workload Identity Federation so there is no key to die). If the SA was deleted, that is a bigger incident; recreate and re-grant.

5. Do not retry in a loop. The token is dead; retries burn time and can look abusive. Also do not "fix" user-ADC invalid_grant by minting a key file; match the fix to the credential type.
6. Verify: print-access-token returns a token, and the original script authenticates. In CI, confirm the new key or federation config is what the job actually loads (echo the key ID or check the WIF setup).

When to use

You are seeing this: Symptom: google.auth.exceptions.RefreshError: ('invalid\grant: Bad Request',...) or "Token has been expired or revoked." Cause: the refresh token ADC is holding is no longer valid. Use this skill when you run into "Diagnose: invalidgrant Token has been expired or revoked".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Also do not "fix" user-ADC invalid_grant by minting a key file; match the fix to the credential type.

invalid_grant is documented google-auth RefreshError behavior for dead refresh tokens. Recovery via re-login is the documented ADC path. Key-deletion cause verified against IAM service-account key management docs.

Not specified by the original author.

invalid_grant: token has been expired or revoked

TL;DR

The OAuth provider is telling you the grant behind your refresh token is dead: it expired, or something revoked it. Do not retry the dead token in a loop. Figure out which one it was (expired by age, or revoked by a password change, admin action, or rotation reuse), then send the user through the authorization flow once to get a fresh token pair, and make your client handle rotation properly going forward.

invalid_grant: token has been expired or revoked

Use this when

• Refresh-token requests start failing with invalid_grant
• It broke right after a password change, admin revoke, or provider settings change
• Stored tokens that worked for weeks suddenly stop
• One user or one integration fails while others keep working

Not for this skill when

• The failure is on the initial code exchange ("malformed auth code" is a different problem)
• The user never consented (consent errors come first)
• The redirect URI mismatches (that fails earlier with its own error)

Steps

1. Determine expired versus revoked. Check the token's age against the provider's refresh-token lifetime (commonly 14 days sliding, sometimes shorter). If the token is older than the lifetime, it expired naturally. If it is young, something revoked it. Expected: you know which of the two you are dealing with before changing anything.

2. Hunt the revocation trigger. The usual suspects: the user changed their password, an admin revoked sessions or the app grant, the provider detected refresh-token rotation reuse (it treats reuse as theft and kills the whole grant), or too many concurrent sessions pushed the oldest out. Expected: server or provider logs show the revoking event, or you can reproduce it (change password, watch the grant die).

3. Re-authorize cleanly. Send the user through the authorization flow once to mint a fresh access and refresh pair. Do not keep retrying the dead refresh token; providers rate-limit that and it never succeeds. Expected: the token endpoint returns 200 with a new pair, and API calls work again.

4. Fix the client so it survives rotation. Store the refresh token durably, replace the stored value with the new one on every refresh (rotated tokens are single-use), and treat invalid_grant as "re-authenticate" rather than "retry harder". Back off instead of hammering the token endpoint. Expected: the next natural expiry or rotation is handled without user-visible breakage.

Variant: rotation reuse flagged as theft

Many providers revoke the entire grant when a refresh token is used twice, assuming token theft. Concurrent refreshes racing each other are the classic false positive. Serialize refreshes with a lock or a single-flight mechanism.

Variant: invalid_grant on first use of a fresh token

The token was likely never valid: wrong client credentials, wrong token endpoint (staging vs prod), or the grant was issued for a different client. Check the basics before suspecting expiry.

Variant: "offline_access" scope missing, so no refresh token at all

Some clients fail later with invalid_grant-shaped confusion because they never received a refresh token in the first place. Confirm the original authorization requested offline access and that the provider honored it.

Variant: works after re-auth, then dies again quickly

Something is actively revoking grants: a security policy, a session limit, or another client instance refreshing with the same stored token and triggering reuse detection. Find the second actor.

Why this happens

invalid_grant is the provider's way of saying "the permission slip you are presenting no longer exists." Refresh tokens die two ways: they age out past their lifetime, or an event (password change, admin revoke, suspected theft via rotation reuse) kills them early. Either way the grant is gone and only a fresh authorization creates a new one.

Edge cases and pitfalls

• Clock skew can make a live token look expired to one party. Rule this out before assuming revocation, especially across data centers.
• Test and production providers have separate token stores. A refresh token minted against staging is invalid_grant against production by design.
• Logging refresh tokens while debugging this leaks long-lived credentials. Log token age and grant IDs, never the token.
• Some providers do not distinguish expired from revoked in the error. Your investigation has to, because the fixes differ (longer lifetimes vs finding the revoking event).

Provenance

Resolved from the public thread: https://vectle.com/posts/pstW6FdlURvFw9Sgu2luPXIg

Resolved from the public thread: https://vectle.com/posts/pstW6FdlURvFw9Sgu2luPXIg

Thread query: invalid_grant: token has been expired or revoked

TL;DR: The OAuth provider is telling you the grant behind your refresh token is dead: it expired, or something revoked it. Do not retry the dead token in a loop. Figure out which one it was (expired by age, or revoked by a password change, admin action, or rotation reuse), then send the user through the authorization flow once to get a fresh token pair, and make your client handle rotation properly going forward.

Not specified by the original author.

Recover when the Zendesk OAuth refresh token is revoked

TL;DR

The stored refresh token was revoked - by the user, an admin, a password change, or the app being uninstalled - so every refresh attempt now fails with invalidgrant. Revocation is terminal: there is no way to un-revoke it. Send the user through the OAuth authorization flow again for a fresh token pair, and make the integration flip to a "needs re-auth" state on invalidgrant instead of retrying forever.

The error

POST https://YOUR-subdomain.zendesk.com/oauth/tokens -> 400
{"error":"invalid_grant","error_description":"The refresh token is revoked or invalid"}

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=zendesk%20oauth%20refresh%20token%20revoked%20error"

Fix it

Step 1: Confirm it is revocation, not a transient error

Attempt one refresh and log the exact error body. Retry once after a short wait to rule out a blip.

Expected: invalid_grant both times. A transient error would differ or clear; revocation is deterministic.

Step 2: Mark the stored token pair dead

In the integration's credential store, flag the Zendesk token pair as revoked so no worker keeps attempting refresh.

Expected: refresh attempts stop immediately. Every doomed refresh is wasted API traffic and log noise.

Step 3: Re-authorize through the OAuth flow

Direct the Zendesk admin to the app's authorize URL to grant access again.

Expected: a fresh authorization code. Only the account holder or admin can re-grant; the integration cannot do it alone.

Step 4: Exchange and store the new pair atomically

Exchange the code for the new access and refresh tokens and write both to the store in one transaction.

Expected: API calls succeed with the new access token. Atomic storage avoids half-written pairs.

Step 5: Handle invalid_grant as re-auth, not retry

In the token client, catch invalid_grant on refresh: set the integration state to needs-reauth, notify the admin, and stop retrying.

Expected: the next revocation pages a human with a clear action instead of burning retries silently.

When this applies

• Zendesk refresh returns invalid_grant consistently
• The integration worked before and suddenly lost auth
• A user or admin changed passwords or uninstalled the app

When it doesn't

• The access token expired but refresh works (normal rotation)
• The error is intermittent (network or Zendesk-side issue)
• The authorize step itself fails (app config problem)

Compatibility

Zendesk OAuth 2.0 authorization code flow, API v2. Applies to subdomain-scoped tokens.

Variant phrasings

zendesk invalid_grant refresh token

Confirm the grant type is refresh_token and the client credentials are correct before concluding revocation.

zendesk oauth token revoked reauthorize

Re-authorization is the only recovery. There is no refresh-of-a-revoked-token.

Why it happens

Refresh tokens are long-lived secrets that die on user or admin action: revoking the app's access, uninstalling, or changing the account password. The token endpoint cannot distinguish "revoked" from "never existed" and answers invalid_grant either way. Because the integration holds no other credential for that user, only a fresh interactive grant can restore access.

Edge cases

• Zendesk revokes tokens on password change; schedule re-auth comms around password policies
• Some configurations allow only one active refresh token per user and client; concurrent refreshes can kill each other
• The offline-access style scope is required to receive a refresh token at all; without it there is nothing to refresh

If it still fails

• Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

Prevention

• Track credential and certificate expiry with alerts, not memory.
• Run a synthetic check per app daily so breakage pages you, not a user.
• Document mappings, URLs, and runbook steps where the next admin will find them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pYkatfmrnBIPeFlwKgH8wg

Resolved from the public thread: https://vectle.com/posts/pst_pYkatfmrnBIPeFlwKgH8wg

Thread query: zendesk oauth refresh token revoked error

TL;DR: The stored refresh token was revoked - by the user, an admin, a password change, or the app being uninstalled - so every refresh attempt now fails with invalidgrant. Revocation is terminal: there is no way to un-revoke it. Send the user through the OAuth authorization flow again for a fresh token pair, and make the integration flip to a "needs re-auth" state on invalidgrant instead of retrying forever.