This was working perfectly fine until we don’t have Rotating refresh token.
Issue started since Rotating refresh token feature is live.
Problem:-
Using offline access, we receive both access token and refresh token.
But when access token expires after some time, we exchange refresh token (that we received in step#1) to get access token (may be after 1hour)
We receive “error_description”: “Unknown or invalid refresh token.”
Unable to generate OAUTH Access token from refresh token ,Refresh token keeps expiring.
{
“error”: “invalid_grant”,
“error_description”: “Unknown or invalid refresh token.”
}
Also we could see that the option to configure the rotating refresh tokens Inactivity expiry time, Absolute expiry time, Reuse interval or leeway are missing.
These are not present where we create the application. The links in those tables take us to auth0 documentation.
Is auth0 is used internally in Jira? If yes, how can we access auth0 to change the setting, if possible share URL for auth0 for our instance: https://sailpointbhushan.atlassian.net/
Using offline_access, a pair of access_token and refresh_token is returned, and let’s call them AT1 and RT1.
When AT1 expires, RT1 can be used to exchange for a new pair - AT2 and RT2.
And likewise, when AT2 expires, RT2 should be used to exchange for a new pair. If RT1 is used instead, an error of “unknown or invalid refresh token” will be returned.
If the refresh tokens have been rotated accordingly but the error was still returned, could you please DM me the client_id for further investigation?
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.
