invalid_grant error when refreshing a restored OAuth 2.0 refresh token

Short answer

No, invalid_grant is not guaranteed, and nothing in OAuth 2.0 (RFC 6749) gives a "restored" token any special treatment. The authorization server cannot tell that you copied a token out of a backup; it only compares the presented string against its own record of that token's state. If the record is still active, the refresh succeeds exactly as it would have before the restore. If the record is revoked, expired, or superseded, the server returns invalid_grant.

The restore is therefore not the cause. The cause is whatever happened to the token's server-side state between issuance and now.

What invalid_grant does and does not tell you

RFC 6749 section 5.2 defines invalid_grant as the error for a grant the server will not accept. It is deliberately coarse: revoked, expired, rotated-away, wrong-client, wrong-endpoint, and malformed grants all collapse into the same code. Some providers add a proprietary error_description or reason code; many deliberately do not, to avoid leaking token state. Treat the bare code as "this grant is dead," not as a diagnosis.

Rotation is the most common explanation

RFC 6749 section 6 says the server may issue a new refresh token in a refresh response, and if it does, the client must discard the old one. Rotation is optional and provider-specific. Where it is enabled, the previous token is invalidated the moment the new one is issued, so a backup taken before that refresh already contains a dead token. Some implementations add reuse detection: presenting a rotated-away token is treated as a possible theft signal and can revoke the entire token family, including the currently valid one.

This also answers the rotation question. The server does not rotate "because the token was restored." It applies the same policy it always applies; the restore is invisible to it. If the provider rotates, you get a new token on the next successful refresh. If it does not, you get the same string back.

Other server-side states that produce the same error

• Explicit revocation: logout, password change, consent withdrawal, admin action, or a security incident. Restoring a copy cannot undo a revocation.
• Lifetime limits: an absolute expiry or an idle window. Both are provider-specific, so a token can be locally intact and server-side dead.
• Binding mismatch: a different client_id, client secret, redirect URI, scope set, tenant, or token endpoint than at issuance.
• Request shape: wrong grant_type, or sending the token as a client credential instead of as refresh_token.

Should the client validate the token's integrity?

Usually there is nothing to validate. Refresh tokens are opaque to the client by design, and authenticity is enforced by server-side lookup. A minority of providers use a structured (JWT-format) refresh token, and only then could you parse claims, but local parsing still is not proof of validity, because revocation and rotation leave no trace in the token itself.

What is worth validating is your own storage: that the restored value is byte-identical (checksum it), that it was decrypted with the correct key, and that it landed in the environment whose configuration matches the issuing client.

Minimal verification steps

1. Stop retrying. If the provider has reuse detection, repeated attempts can revoke the whole family.
2. Compare current configuration against issuance: client_id, secret, redirect URI, scopes, token endpoint, tenant.
3. If the provider exposes RFC 7662 introspection or RFC 7009 revocation, query the token to see whether it reports active, revoked, or unknown. Many providers do not allow introspecting refresh tokens.
4. In a test tenant, obtain a fresh refresh token and refresh once. Success proves the client configuration is sound and isolates the problem to the restored token's state.
5. Check authorization server logs for a specific reason code.

The one detail that changes the recommendation

Which authorization server and version issued the token? Rotation and reuse-detection policy is provider-specific, and it determines whether a single careful retry is safe or whether you should not retry at all. Without that answer, treat the restored token as unrecoverable and re-run the authorization flow.

Uncertainty note: provider behavior varies widely, and this describes RFC 6749-era behavior rather than any single vendor's policy. Confirm against your provider's current documentation before acting.