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

Announcements
, ,
64

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

Thanks!
-kevin

65

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!

66

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!

67

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.

68

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.

69

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
70

@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.

5 Likes
71

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.

5 Likes
72

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 nnikolaevsky@atlassian.com, or book a call with via Calendly here.

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

P.S.
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.

2 Likes
73

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

1 Like
74

@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:

2 Likes
75

Can we maybe freeze this thread and start a new one? @bentley ?

3 Likes
76

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:

  • automatic reuse detection
  • absolute lifetime
  • inactivity lifetime and what ā€œinactiveā€ means
  • Atlassianā€™s plans and how that might affect the absolute lifetime
  • changes to the migration strategy

ā€¦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.

1 Like
77

Hey everyone, hoping the following points will address most of your comments:

  • The dates on this post and the migration banner have been updated.
  • We agree that 70+ comments is a little long, weā€™ll be starting a new announcement and locking this thread.
  • In the new announcement weā€™ll give a brief summary of the changes weā€™re making to the 3LO docs. The doc update will cover the information previously discussed in this post:
    • The new deprecation date
    • Info about re-use detection
    • The configured re-use leeway and what it means
    • Our absolute lifetime and inactivity lifetime configuration and description of what they are and what they would mean to you
    • Added a section about 403 errors and possible causes

Regarding the 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 absolute and inactivity lifetimes might take a little longer but weā€™ll let you know about that in the new post.

As always, if you have any questions please feel free to reach out to me here, submit a Dev Help ticket, email me on nnikolaevsky@atlassian.com, or book a call with via Calendly here.

Cheers,
Nir

78

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:

  1. Simply ignore that requirement for now and hope it goes away within one year, or
  2. try to find and implement workarounds now to be prepared in case the requirement is still there after one year. If the limitation goes away in time, we will have to rework our code to remove the workarounds.

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).

3 Likes
79

Hey @tbinna,

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

  • The new OAuth config will only apply from this month, which means as long as we complete the migration before December 2022, no token family should experience absolute lifetime expiration.
  • This effectively gives the team a buffer of 3 months to complete the migration beyond their target date.
  • Iā€™ve also made sure to pass on all the comments about the absolute lifetime from 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:

  • Weā€™re unable to reliably distinguish between ā€œconfidentialā€ and ā€œpublicā€ clients (in OAuth nomenclature). Especially with the authorization code flow applying in both environments. Token binding is something weā€™ve also explored to address some of the security risks with leaked tokens.
  • Thereā€™s three main areas weā€™re concerned about with token exposure:
    1. Server, browser or proxy logs
    2. On devices such as mobile or browser extensions. Future plans for PKCE will help in some of these cases also.
    3. Databases and database backups

The ā€œdialsā€ we have to mitigate these risks within the confines of OAuth are really:

  • Controls around who/what can request offline_access
    • This isnā€™t something weā€™ve explored in depth, given apps can freely request the scope today
  • Rotating refresh tokens to invalidate stolen or leaked tokens
  • Expiring refresh tokens to reduce the impact of leaked tokens - e.g. an exposed database backup wonā€™t impact users whoā€™s tokens have expired

Hopefully that helps explain why the control applies to all OAuth 2.0 Integrations.

80

Thank you, Nir. I do understand the points made by the security team but I do think for some of the points there are other/better solutions.

I understand that it is not possible to distinguish between confidential and public OAuth clients without additional information. However, all shared/distributed OAuth clients need to be approved by Atlassian anyway so Atlassian could, for example, ask applicants to declare if they are running a public or confidential client and add the requirement for rotating refresh tokens accordingly.

Clearly, this would not help with the server logs, proxy logs, or database backup issue highlighted. However, for me, these points count towards the general security practices of app vendors. With bad security practices, secrets could be leaked just the same way in a Connect app or many other places.

To introduce PKCE makes sense to me, even for confidential clients after learning about auth code injection. I am still looking for an attack that truly explains why we need rotating refresh tokens for confidential clients. If anyone has insights on this I would be happy to learn about it.

81

As promised, weā€™ve created a new announcement with all the updated details. This thread will be locked now, for any questions or comments please go to the new announcement here.

1 Like