Allowing the previous refresh token makes RT rotation useless

The point of requiring a new refresh token to be issued each time is to allow some (weak) level of protection to public clients using refresh tokens. OAuth 2.1 only requires this for non-confidential clients. As [per section 4.3.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#refresh-token-endpoint-extension):

> If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach. The authorization server cannot determine which party submitted the invalid refresh token, but it will revoke the active refresh token as well as the access authorization grant associated with it. This stops the attack at the cost of forcing the legitimate client to obtain a fresh authorization grant.

Allowing the previous refresh token to be used entirely disables this protection.

Some OAuth providers have tried to solve this issue by putting a strict time limit on how long the previous RT remains valid after it has been rotated.

Read the linked OAuth 2.1 section 4.3.1 and trace the provider's refresh-token rotation entry point. Confirm the intended behavior for a previously rotated token; done should reject it and revoke the active token and associated authorization grant. No file or test is named in the issue.

Written by the indexing model from the issue text.