The error was returned because the rotating refresh token was reused. As mentioned in the original reply, each refresh token should only be used once only and the newly retrieved refresh token should be used for the subsequent exchange. More details have been provided in DM.
I am facing same problem while consuming the api by multiple threads/applications,
I can see the in reuse interval of 10 minutes breach detection is disabled and both RT1 and RT2 are woking fine.
but the problem is when 5 threads using RT1 and gets 5 different tokens i.e. RT2.1, RT2.2, … RT2.5 because RT1 is still works as its a reuse interal
and after the reuse interval expire only the latest one between RT2.1, RT2.2, … RT2.5 will valid.
Is there any way to identify which is the latest and valid refresh token when multiple RT generated during reuse interval?
Reuse within leeway (i.e. “reuse interval of 10 minutes”) is designed to aid concurrent calls:
In the event of reuses within leeway, all valid RT2s (i.e. RT2.1, RT2.2, … RT2.5) will be able to be used to exchange for new token pairs and receive RT3s (i.e. RT3.1, RT3.2, … RT3.5).
An invalid token refresh request (e.g. reuse outside leeway, unknown/incorrect RT etc.) will revoke all existing tokens retrieved from the same chain as it’s deemed to be suspicious activity.
As such, identifying the latest RT will not be necessary. What I suspect could have happened in your described issue is that some of the RT1 exchanges happened outside leeway (after the reuse interval) and hence invalidated the entire token chain (i.e. all tokens generated from RT1).
The rotating refresh token is risky for production usage as if reuse detected, it will brake all the things.
Is Atlassian thinking of new introducing new grant_type such as password or client credentials which does not require user intervention.
The client credentials grant flow is not applicable in cases where principal consent is required and we do not support the resource_owner grant flow, due to obvious security gaps: this flow will be deprecated in future versions of the OAuth2 specification.
RRT re-use does not aim to address synchronization problems in the client implementation and our re-use policy will continue to revoke chains of reused RRTs. It is advisable to dig into where these synchronization issues may appear in your client app and guard updating with some type of mutual exclusion. RRTs will also break in the event that you are sharing the refresh token amongst various processes or instances as well.