@VincentFiestada I am curious if you have had any feedback or came up with any solution for the parallel execution issue you are describing above?
Our first attempt to migrate to rotating refresh tokens failed, so we are re-assessing the impact of this change and further improve our knowledge on rotating refresh tokens to better understand where things could go wrong. Similar to what you are describing, we have a deployment that allows parallel execution of requests and scales dynamically to more or fewer instances.
With persistent refresh tokens, the refresh token does not change over the lifetime of an OAuth2 installation. Hence, the refresh token can be used across multiple instances and be easily read by many consumers in parallel. However, with rotating refresh tokens the refresh token becomes a shared mutable state, and hence refresh token reads and writes have to be synchronized between consumers.
The RFC on OAuth 2.0 Threat Model and Security Considerations actually contains a note on this issue that reads:
Note: This measure may cause problems in clustered environments,
since usage of the currently valid refresh token must be ensured. In
such an environment, other measures might be more appropriate.
Based on our study on the topic of rotating refresh tokens, OAuth2 is not a simple “one-size-fits-all” solution anymore. As I understand, rotating refresh tokens and PKCE are measures to address security concerns with public OAuth clients (SPAs, desktop/native or mobile applications). However, applying this same measures to private/confidential clients (our use case) does not seem to be always necessary/appropriate and may cause issues as highlighted in the RFC reference above.
@NusratSultana @Nir would you be able to comment if these concerns have been considered when requiring rotating refresh tokens for all OAuth2 clients? If yes, may I ask what is the reasoning?