Thanks @Nir! Do you have a sense as to when this change will go live?
Thanks @Nir! Do you have a sense as to when this change will go live?
Is the countdown to
Inactivity lifetimefrom 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
Inactivity lifetimefor 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.
@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?
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 email@example.com, or book a call with via Calendly here.
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
@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.
Can we maybe freeze this thread and start a new one? @bentley ?
Thanks for the extension, @Nir. I think many of us, especially those that haven’t kept up with this thread, would appreciate another official post and email consolidating the things discussed here, such as:
…so that we have a central place where the entire authentication behavior is described in detail. I for one am only learning about the absolute lifetime now since this thread fell off my radar, but this is definitely something useful to know. I agree with @david that learning about these things in a thread with so many disparate comments is not very efficient.
Hey everyone, hoping the following points will address most of your comments:
inactivity lifetimeconfiguration and description of what they are and what they would mean to you
403errors and possible causes
absolute lifetime and our migration to a new OAuth provider, unfortunately I cannot provide you any more information at the moment. The work has already been roadmapped by one of our teams and as far as I know it should be done in about 9 months, but there are no guarantees at this stage. All I can say is that if everything goes according to plan, the migration will be done before a year has passed and your refresh tokens shouldn’t hit their
absolute lifetime expiration date. I have informed the team of the situation and the potential pain your users will experience if the migration isn’t done in time. I do want to emphasise however that these changes are purely on our end and shouldn’t impact your migration and work.The documentation update and new post should go live by this weekend. The configuration update for
inactivity lifetimes might take a little longer but we’ll let you know about that in the new post.
Thanks for the update and timeline, @Nir.
I do want to emphasise however that these changes are purely on our end and shouldn’t impact your migration and work.
I just wanted to highlight this point because I am not quite sure if the impact on vendors is clear to Atlassian.
The impact of the “absolute lifetime” for our application is massive and exactly as what @jscalise described in his post. At the moment Atlassian is saying it cannot give any guarantees if and when the “absolute lifetime” limitation goes away.
As a vendor we have two options:
Option 1 is a timebomb. If Atlassian cannot get rid of the requirement in time, it’s on vendors to try and come up with a fix/workaround.
Provided Atlassian does not manage to remove the limitation: The longer we wait the less time we have to implement the fix. Also, it’s on vendors to remember to fix this in time because the breaking change is basically announced now, or following this change notice was announced mid-2021.
Option 2 seems the more reasonable approach for vendors and impacts the migration and work required.
Either way, this issue does affect the migration and our work and I feel Atlassian should make a commitment to either keep the “absolute lifetime” or give a guarantee that it will be removed within one year.
I repeat myself on this but, I still have some doubts that what Atlassian is doing here is the right approach and I still think that rotating refresh tokens is not a “one-size-fits-all” solution for all types of OAuth2 clients (we are running a confidential client, i.e. everything remains server-side). I may open a new thread to discuss this separately but I am still looking for valid reasons on why we are actually doing this (for confidential clients).
I’ve spoken to the team who’s currently working on the OAuth migration. They confirmed that they are targeting August 2022 to complete the work, but like with any long running project, there could always be unexpected delays which is why we can’t commit to a specific date at this stage. On the other hand, we’re fairly confident the migration will be done before the first absolute lifetime expiry because
absolute lifetimefrom this thread to the team leads so they know our partners care about this and the impact it could have on your users if the project slips beyond December.
Finally, regarding why we’re rolling rotating refresh tokens to all OAuth apps, including ones for confidential clients, I’ll have to provide an answer from my security colleague here. I know this has been shared with you in a DEVHELP ticket but I’ll quote it here for any other partners interested in our answer to this.
There are a few reasons we’re rolling out the change to all apps:
The “dials” we have to mitigate these risks within the confines of OAuth are really:
Hopefully that helps explain why the control applies to all OAuth 2.0 Integrations.