Superseded: 31 January 2022 - Action required - Deprecating persistent refresh tokens


Can someone from Atlassian pls help with the issue I raised. I was asked to create a ticket which I did here (last week).

We don’t want to leave our changes till the very last minute.


Hey @FatmehShuman,

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.


1 Like

Hi vladyslavi,

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.

For information on how to do that, see OAuth 2.0 (3LO) apps

Hope this helps! Let us know if you have any follow up questions.

Hi @DesislavaMineva ,
Sorry, I think this one was missed - I’ve followed up with Nusrat for you.

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.

Hey @KevinGreenan and @FatmehShuman, sorry for keeping you waiting! I wanted to make sure I give you a complete reply.

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.

1 Like

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?

Thank you.

Hi @Nir

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?

Any insight into this decision would be great.



Thanks @Nir! Do you have a sense as to when this change will go live?


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?

The countdown begins from when the user first did the OAuth flow.

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?

I don’t want to leave you without an answer for much longer so I’m going to give you one based on my theoretical understanding. I’ll work with the team to test it and double check, I’ll update you with what I find.

But in the meantime, here’s my understanding:
Rotating refresh tokens are shared across sites, so when a user authorises a Jira instance on the 1st of Dec, 2021 an absolute lifetime timer will start for the token family, and an inactivity lifetime timer will start for the individual token. When the user authorises another Jira instance on the 15th of Dec 2021, the absolute lifetime timer stays the same (expiring 1st of Dec 2022) but the inactivity lifetime resets.

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?

Re: the deadline, I’m in the process of reviewing our migration strategy with the team. I’ll get back to you with an answer on this as soon as I can!

Hey @adam.markham, at the moment according to Auth0 a rotating refresh token requires an absolute lifetime config, meaning we have to include it and one year is the longest absolute lifetime period available.

I do have some good news though, we’re currently working on migrating to a different OAuth provider which will give us more granular controls over refresh tokens and in the future we should be able to completely remove the one year absolute lifetime, but I can’t give anymore info about this at the moment. I know one of our teams is working on it, but it will be at least another 9 months before shipping. If it does happen we’ll be sure to announce it!

Hey @KevinGreenan, I can’t give you a date right now but the team is on it and we’ll update you as soon as the change is live.

Thanks for your updates Nir. I look forward to the confirmation from your team as we need to manage communication (re having to re-authorise on go-live) with our users accordingly.

Thanks @Nir that makes sense if it’s a limitation of Auth0. We’d be interested in hearing about the new Auth0 provider you’ll use as the absolute lifetime on the refresh token will be a blocker for our use cases.

1 Like

@Nir I just noticed your comment about lifetime. These are more announcements (in comments) that are seriously worrying to us. The impact of an OAuth connection breaking is quite severe for our mutual customers who are using our app for their daily work and rely on it working. As I understand (from previous discussions) there is no way for a vendor to tell why a connection for a customer is broken (inactivity, absolute lifetime limit, or other) and hence we have no way to communicate to the customer why they have to reauthorize the connection. I can predict that this will lead to a lot of confusion among our customers and we will likely not have an answer for them.

@Nir @NusratSultana @mpaisley
To sum up:
We are now one week away from this change going live but there are changes to this deprecation still being worked on by Atlassian. Browsing through the comments in this thread, it may be a good idea to take a step back and make sure the impact of this change on vendors has been thoroughly considered and thought through and that the change is properly understood and finalized by Atlassian as well. After that, it would be good to summarize all the comments and advice given in this thread in a new change notice (including token lifetimes, grant lifetime, impact on clustered environments, etc.) with a new deprecation date which gives vendors enough time to understand the implications of the change and to implement the necessary downstream changes. Or maybe it would be even better to delay this change all together until you have migrated to the new OAuth provider.


I agree with @tbinna in that there has been a number of new announcements and back and forth over some unclear implementation details throughout this comment section that are very worrying to our team. Due to this coupled with the fact that things are still being actively worked on by the Atlassian team a week out, I think taking a step back to analyze vendor impact and summarizing all that has been discussed in a new change notice would be greatly beneficial and reduce the risk of negatively impacting vendor customer experience and possibly breaking applications. Possibly even waiting until the new OAuth migration to be finished.

In regards to the newly announced Absolute lifetime, we have a similar use case to @adam.markham in that a user authorizes and then sets up long running automations that they don’t give further input on once they are setup and running. Those automations are then used and relied on by a wide number of other users and our app has been built assuming a user will never need to re-auth. Imposing a new absolute lifetime would be a massive blocker for us in trying to facilitate re-auth and communicating this to customers. I understand that it is a limitation of Auth0, but it is also a newly imposed restriction that we have never had to consider until now.

It sounds like the OAuth migration may get done within 9 months, but if it doesn’t and extends past the first 1 year Absolute lifetime period then we are going to be faced with a huge negative impact to customer experience that we will need to figure out how to mitigate.


Hey everyone, I have an update for you!

Given the recent changes the team decided to reevaluate our migration date.

So what are we doing?

  1. We are moving the migration deadline to 31/01/2022, extending the deprecation by an additional 2 months. Due to security concerns this will be the final extension for this deprecation.
  2. Once we hit the 31/01/2022 we’ll progressively roll out rotating refresh tokens to all 3LO apps.

The dates on this post, the docs, and the Developer console will be updated next week, but this is an offical extension.

I want to stress out that ultimately we want the best outcome for you and your users, and to me that means balancing platform security with fair migration terms. If you’re coming across any issues with the migration or you believe that you encountered a bug, we want to help you! please comment here, submit a Dev Help ticket, email me on, or book a call with via Calendly here.

@FatmehShuman @tbinna @jscalise I hope this addresses your concerns about the deadline!

Just letting you know that I’ve seen the questions about the absolute lifetime, I’m looking into it now and will get back to you about it next week.


Indeed, yes. Thanks for the update, Nir.
I look forward to your findings on the absolute liftetime.

1 Like

@Nir Please post an update on the original post as well. Every developer reading 70 comments before they get to this is not a good use of time.

Tick tock. :hourglass: