One option could be to require that the access token needs to used within X seconds after it has been issued. During this period:
* Old refresh token can be used. Using it will revoke previous "new" tokens (and possibly generate some warnings, especially if new tokens are used after this)
* Using new access token will revoke old refresh token and access tokens, possibly requiring access on dedicated path (something like lookup, essentially confirming that you received it)
This probably should be rate limited to avoid malicious/buggy client filling the revoke list with junk. And it may also make sense to decrease the lifetime of the old refresh token (e.g. if it was originally going to expire in 24h make it expire in 30 minutes) or set maximum of times this swap can happen.
Of course this would still cause issues if e.g. database server where these were stored failed and client had to restore from backups.
* Old refresh token can be used. Using it will revoke previous "new" tokens (and possibly generate some warnings, especially if new tokens are used after this)
* Using new access token will revoke old refresh token and access tokens, possibly requiring access on dedicated path (something like lookup, essentially confirming that you received it)
This probably should be rate limited to avoid malicious/buggy client filling the revoke list with junk. And it may also make sense to decrease the lifetime of the old refresh token (e.g. if it was originally going to expire in 24h make it expire in 30 minutes) or set maximum of times this swap can happen.
Of course this would still cause issues if e.g. database server where these were stored failed and client had to restore from backups.