A user has authorized Jira and Confluence cloud for a particular instance.
If the authorization flow is completed via a single consent, then you will receive just one refresh token and access token pair to access both the products. So, exchanging for one product will invalidate the old token.
But if you are getting two seperate refresh tokens, because you have seperate authorization flow for the two products then, refreshing a refresh token for one product shouldn’t affect another token from another product.
Thanks for your reply @NusratSultana. Unfortunately, it looks like there is an issue then.
Our users do not complete the authorization flow for Jira and Confluence at the same time. The user authorises the Jira and Confluence cloud instances separately so we have two separate refresh and access tokens for the Jira and Confluence instances.
Can the issue I described be investigated pls? If you need more info, pls reach out to me.
This is holding us off from migrating to rotating tokens because we want this migration to be as seamless to users as possible. In this current state, it’s going to mean we have to ask our users to re-authorize both Jira and Confluence cloud for every instance (where they use both apps).
In this case, the token pair is issued to the same user for the same app. We proactively refresh the token pair for the same user a few times per day (via a cron-like job). We do not keep old refresh tokens around.
Here is the behavior we are seeing:
User completes OAuth2 flow, which issues the first (access, refresh) token pair on day 1
For day 1-29, we refresh the tokens multiple times per day with a cron. We have verified that the stored (access, refresh) token pairs change with each run of the cron.
On day 30 the cron fails to refresh the tokens with a 403.
Note that we are using the (access, refresh) tokens many times per day for days 1-30 without issue.
For example, a user completed their OAuth2 flow on 09/28/2021 at 5 PM. The cron refreshed the user’s (access+refresh) tokens hundreds of times and used the resulting access tokens to access the API dozens of times. Then, the cron tries to refresh at 3 PM on 10/28/2021 and succeeds. The cron gets a 403 when it tries to refresh at 6 PM on 10/28/2021. This suggests that there is an additional limitation per user+app.
To be clear, we am following the procedure documented here. Are we incorrect in assuming that the newly minted refresh token in the (access, refresh) pair has a 30d expiry?
We have seen this behavior across multiple users. While there is a chance we are doing something wrong, I feel that the things like reuse detection feature would lead to faster and non-deterministic failure here, since that we are refreshing each user’s tokens many times per day.
Can it be clarified if Apps that utilize the OAuth 2.0 3LO integrations that are configured via the usage of application links are impacted? This is an OAuth 2.0 integration but the offline_access scope usage is not clear (possibly encapsulated), nor does it leverage the developer console.
Maybe I can simplify my line of questions using the Auth0 rotating refresh token behavior, outlined here.
Auth0 has refresh tokens and refresh token families, where a refresh token family is the chain of rotating refresh tokens issued after a user completes the OAuth2 flow. Auth0 states: The lifetime does not extend when tokens are rotated.
This means that the expiration applies to the family, not individual refresh tokens. Is this the case with Atlassian? If so, this means that when using rotating refresh tokens, with offline access, you require a user to re-initiate the OAuth2 flow every 30 days, correct?
Hi Kevin - Did you get a response from Atlassian on this? This issue you highlighted is a concern for us too because we wouldn’t want our users to keep re-initiating the OAuth2 flow. It kind of defeats the purpose of offline access.
I have not heard anything yet, but are continuing to see that users need to re-initiate the OAuth2 flow after 30 days. Again, we are refreshing each users rotating token many times per day, so this does appear as though it applies to the “family” of rotating tokens, not individual refresh tokens.
I’ll let you know if I hear anything outside of this thread.
I think the docs have been updated to cover this now, but in case you didn’t see it:
If you want to, you can switch the new behaviour on when you’re ready BEFORE the 30th November 2021 in the developer console. After the 30th November we will begin automatically moving all apps to the new behaviour and opting in will no longer be an option.
If your refresh token has expired, you have two options:
Initiate the entire authorization flow from the beginning again.
Use a refresh token to get another access token and refresh token pair.
Hi @DesislavaMineva ,
Apologies for late reply. The behaviour you described from Auth0 is the expected behaviour. We have updated the leeway to 10min(previous 3sec) few weeks ago. We are also working on the documentation to make this leeway update announcement.
Following your comments we checked our rotating refresh tokens (RRT) config and found that it didn’t match the behaviour we described, nor the one we were going for. This config mistake on our end was what led to your experience, but again, it wasn’t intended. This also prompted us to conduct a quick review of our RRT settings and finally we agreed on the following as a balance of security and user experience: Absolute lifetime - 1 year (users will have to re-auth once a year, regardless of use) Inactivity lifetime - 90 days ~ 3 months (users who are inactive for over 3 months will need to re-auth).
We are now working to implement these changes. Once they are live we will update our 3LO docs. Thanks again for your questions, hope this answers everything.
Thanks for the update Nir. Given the 2 issues that have been reported are now being worked on from the Atlassian side, is 30-Nov-2021 still the deadline?
We haven’t been able to cut over yet due to the issue I had reported on 22-Oct. I’ve now been told it’s being worked on and there will be an update on Monday.
This feels a bit last minute and I don’t know what the fix will mean for us. Would we have to make more changes at our end and re-test again? Would we have to inform our users to re-authorise again? We wouldn’t want to leave it till the very end to get users to re-authorise.
As of now, our switchover is on hold until we know what’s going on with the other issue.
Also Nir - just to confirm regarding the lifetime mentioned above.
Is the countdown to Absolute lifetime and Inactivity lifetime from the day the user first did the OAuth flow? i.e each user will have their family of tokens. So it’s not from when we switch over our app to rotating tokens?
Also, what happens if the user authorises a Jira instance on 1-Dec-2021 and then on 15-Dec-2021, they authorise another Jira instance. What will be the Absolute lifetime and Inactivity lifetime for both of these?
We have a use case in our product where we use a 3LO app to authorize scheduled and long-running automation tasks that don’t have any user input once setup and running.
Therefore we’re concerned about the Absolute lifetime and Inactivity lifetime being introduced on the refresh token. As we understand it regardless of how many times you refresh a token reauthorization would still need to happen at a minimum, once a year. This would break the behaviour of this use case every year for our customers if they need to reauthorize and isn’t a great experience for them to have to reauth every year.
Previously the refresh token had no lifetime and we could always use it to refresh the access token which is why we were able to use it in the use case of long-running and scheduled tasks.
Surely rotating refresh tokens would mitigate against needing to have a global lifetime on refresh tokens?
Also how do you define inactive users in the context of the Inactivity lifetime? Is this users that haven’t refreshed their token in the last 3 months?