invalid_grant on Refresh Token Retry After Network Timeout During Rotation

Direct answer

The error response invalid_grant alone does not let a client tell whether the refresh token was genuinely revoked/expired or merely already rotated by a prior request that timed out. RFC 6749 provides no idempotency token or distinct error code for this case, and the OAuth 2.0 Security BCP (RFC 9700) does not mandate a way to differentiate them.

Likely explanation vs. confirmed facts

• Likely explanation: The network timeout occurred after the authorization server had already processed the refresh request, rotated the token, and stored the successor. The client’s retry therefore presents an invalidated token and receives invalid_grant.
• Confirmed facts:
  • RFC 6749 §6 defines the refresh token grant but specifies no replay‑protection or idempotency mechanism.
  • RFC 9700 (OAuth 2.0 Security BCP) recommends refresh‑token rotation for public clients and treats reuse of a rotated token as a potential theft indicator, optionally revoking the whole token family.
  • The BCP acknowledges that strict immediate invalidation can lock out legitimate clients whose response was lost, and permits a short grace window as a recognized trade‑off, but does not prescribe a specific duration.

Steps for this case (when you do not control the server)

1. After sending a refresh request that times out, mark the used refresh token as "possibly rotated" and do not immediately retry with the same token.
2. If a retry is unavoidable, use exponential back‑off and retry the identical request.
3. Should the retry return invalid_grant, treat the grant as unrecoverable: stop using the refresh token, keep any still‑valid access token until it expires, and initiate a recovery flow (e.g., redirect the user to re‑authenticate).
4. Do not persist a new token before the retry because the client never received it; persistence is only useful for protecting against a crash after a successful response.

When a server‑side mitigation is available

If the authorization server implements one of the following, the client can safely retry:

• A grace window during which the previous refresh token remains valid for a limited time (typically seconds to a few minutes).
• Sender‑constrained refresh tokens (e.g., DPoP or mTLS binding) that cause a replayed token to fail authorization regardless of rotation state.

In that scenario, after a timeout the client may retry the same request; if the server accepts it within the grace period or rejects it due to sender‑constraint mismatch, the client can distinguish the outcomes.

Missing diagnostic detail that changes the recommendation

Ask the server administrator (or consult its documentation): Does the authorization server provide a grace period for rotated refresh tokens or support sender‑constrained refresh tokens? If the answer is yes, follow the retry‑with‑back‑off approach; if no, fall back to the recovery flow described above.