1👍
Security considerations are mentioned in the RFC 7009 https://www.rfc-editor.org/rfc/rfc7009#section-5
You can have also an attack on TLS (HTTPS) if it’s not configured/managed properly (insecure TLS versions, ciphers, man in the middle, expired cert, problems with Certification authority, …).
You may have a problem with resource exhaustion on your server. Refresh token needs some resources – e.g. memory, DB record, …
0👍
The description of the security benefit of token rotation in OAuth 2.0 Security Best Current Practice:
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. This stops the attack at the cost of forcing the legitimate client to obtain a fresh authorization grant.
Sounds to me like the intention of recycling is to guarantee the new tokens have exactly one recipient. A grace period, however short, would remove that guarantee. That said, token rotation with a grace period is better than no rotation as it would make it more difficult for an attacker to abuse a leaked refresh token without detection.
Since you are using TLS, another option could be to constrain the grace period to apply only to the current connection…