Google auth invalid_grant expired or revoked refresh token re-login

Not specified by the original author.

TL;DR

Fix for user ADC: ` gcloud auth application-default login If that still fails, remove the stale file first (it lives in the gcloud config directory as application\default\credentials.json) and then log in again.

Steps

1. Full error: google.auth.exceptions.RefreshError: ('invalid_grant: Bad Request', ...) or "Token has been expired or revoked."
2. Meaning: the refresh token in your ADC file (or key-adjacent store) is no longer valid. Common causes: you revoked it in your Google account security page, it expired from long disuse, an admin revoked it, or the ADC file is stale from a previous machine image.

gcloud auth application-default login

3. If that still fails, remove the stale file first (it lives in the gcloud config directory as applicationdefaultcredentials.json) and then log in again.
4. Fix for service account keys: keys do not "expire" this way; invalid_grant on a key usually means the key was deleted from the SA or the SA itself was deleted/disabled. Check the SA exists and the key ID is still listed.
5. Do not:

• Retry in a loop. The token is dead; retries just burn time and can trip abuse detection.
• Copy someone else's ADC file over yours. It is their identity.
• "Fix" it by creating a key file when the real problem is a revoked user token. Match the fix to the credential type.

6. CI note: if CI uses a key file and starts throwing invalid_grant, someone deleted the key or the SA. Rotate: create a new key (or better, move that CI to Workload Identity Federation so there is no key to revoke).
7. Verify: gcloud auth application-default print-access-token returns a token after re-login, and the failing script runs.

When to use

You are seeing this: Full error: google.auth.exceptions.RefreshError: ('invalidgrant: Bad Request',...) or "Token has been expired or revoked." Meaning: the refresh token in your ADC file (or key-adjacent store) is no longer valid. Use this skill when you run into "Google auth invalidgrant: expired or revoked refresh token, re-login".

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.

Verified 2026-09-26: invalid_grant semantics are documented google-auth behavior for dead refresh tokens; the re-login fix path is the documented ADC recovery. Distinct from the DefaultCredentialsError (no credentials at all) case.

Not specified by the original author.

Your stored refresh token is dead (revoked or expired). Run gcloud auth revoke for the account, then gcloud auth login fresh. Retrying the same command will keep failing because the CLI cannot mint new access tokens from a dead refresh token.

ERROR: (gcloud.auth.login) There was a problem refreshing your current auth tokens: ('invalid_grant: Token has been expired or revoked.')

Fix

1. Revoke the dead credential:

   gcloud auth revoke [account]

   Expected: Revoked credentials for [[account]].

2. Log in fresh:

   gcloud auth login

   Expected: full browser consent flow; do not reuse an old approval, complete it end to end.

3. Verify the token refreshes:

   gcloud auth print-access-token

   Expected: a token prints with no error.

4. If it was ADC (application code) rather than the CLI, refresh that store instead:

   gcloud auth application-default login

When this applies

• invalid_grant: Token has been expired or revoked on gcloud auth login, print-access-token, or any command.
• After removing Cloud SDK access at myaccount.google.com permissions, or an admin session revoke.

When it does NOT apply

• First-ever login failing: check the browser completes the flow and the machine clock is correct.
• Your current active account does not have any valid credentials: nothing is stored at all; just log in.
• Service-account key errors: keys do not use refresh tokens; check the key file instead.

Compatibility

• Google Cloud SDK (gcloud) all recent versions; affects user-account OAuth only.

Why it happens

User-account auth relies on a long-lived refresh token to mint 60-minute access tokens. Google-side revocation (user removed third-party access, admin reset sessions, token lifetime policy) kills the refresh token, and the CLI's next refresh attempt returns invalid_grant. Nothing client-side can resurrect it; only a new consent flow mints a replacement.

Edge cases

• If this recurs quickly, check whether a security policy auto-revokes OAuth grants (common on managed corporate Google Workspace).
• Service accounts activated with gcloud auth activate-service-account are immune to this; consider one for automation.
• gcloud auth application-default login writes a separate ADC file with its own refresh token; fix the right store.

This surfaces when the long-lived refresh token stored by 'gcloud auth login' stops working: the user revoked the app's access at their Google account security settings, the admin revoked sessions, or the token aged out. The Google Cloud documentation on gcloud credential storage (docs.cloud.google.com/architecture/bps-for-mitigating-gcloud-oauth-tokens) explains that the CLI keeps a long-lived refresh token precisely so it can mint new access tokens, and that this refresh token 'persists until its expiration conditions are met' - revocation by the user or admin is one of those conditions. The fix is 'gcloud auth revoke' followed by a fresh 'gcloud auth login'. Source: https://docs.cloud.google.com/architecture/bps-for-mitigating-gcloud-oauth-tokens

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.