Behavior of OAuth 2.0 clients when using restored refresh tokens without prior validation

Answer

An OAuth 2.0 client can safely use a restored refresh token only if it is prepared to handle the possible error response from the token endpoint. The specification does not guarantee token validity after restoration; the server will reject a stale or revoked refresh token with an error (typically invalid_grant) and will not issue a new access token. Therefore, skipping pre‑validation is acceptable only when the client can gracefully recover from a failed refresh (e.g., by prompting the user to re‑authenticate) and when the latency or reliability cost of an introspection call outweighs the risk of a failed request.

Confirmed facts

• Refresh tokens are opaque to the client; the authorization server may expire or revoke them at any time.
• When a client presents an invalid refresh token, the token endpoint returns an error response (RFC 6749 §5.2) – most commonly invalid_grant.
• If the refresh token is valid, the server issues a new access token and may issue a new refresh token (refresh‑token rotation).
• The client must treat any error from the token endpoint as a signal to discard the stored refresh token and initiate a fresh authentication flow.

Likely explanation / trade‑offs

The decision to skip validation hinges on two factors:

1. Risk tolerance: Using a potentially revoked token will cause the refresh request to fail. If the application can handle that failure (e.g., show a login prompt) without compromising user experience or security, the risk is low.
2. Cost of validation: Token introspection (RFC 7662) adds network latency and may be rate‑limited or unavailable. If the extra call would noticeably degrade performance or reliability, skipping it may be justified.

Relying on a protected‑resource request to infer token validity is only partially reliable. A successful (2xx) response indicates the access token was valid at that moment, but it does not tell you whether the refresh token is still usable for future refreshes. Conversely, a 401 could stem from an expired access token, network issues, or server‑side problems, not solely from a bad refresh token.

Steps for this case

1. Attempt to use the stored refresh token in a token‑request to the authorization server.
2. If the response is successful, replace the stored refresh token with any new one returned and use the new access token.
3. If the response is an error (especially invalid_grant), discard the stored refresh token and fall back to a full authentication flow (e.g., redirect to the authorization endpoint).
4. Optionally, log the error to monitor how often restored tokens are stale, which can inform future decisions about validation frequency.

Missing diagnostic detail

Whether the authorization server implements refresh‑token rotation and returns distinct error codes for revoked vs. expired tokens would affect how granular the client’s error handling can be. If you can confirm this behavior, you may tailor recovery steps (e.g., differentiate between a temporary expiry and a permanent revocation).