4 Aug 2021 - Action required - Deprecating persistent refresh tokens

@SamWilsonAtlassian We are an integration partner and agree that expiring refresh tokens are generally a good idea, however it feels you’ve gone from one extreme to the other.

A 30 day expiration for refresh tokens will cause customer dissatisfaction because customers who use an integration less than once a month (and for a variety of reasons there are use cases where such a patter makes sense) will have to consent every time before being able to use the integration.

We are requesting that the lifetime of the token be extended to 90 or 180 days. Thanks!



If we use impersonated access to the Jira API on behalf of instance users, will that affect us?

Hey @VincentFiestada, yes the extension is official and was announced as part of a reminder email we sent recently (let me know if it didn’t get to you). Thanks for pointing this out though, we’ll get it changed.

@SamWilsonAtlassian can you please help with my question?

@SamWilsonAtlassian @NusratSultana The new changes should not affect api tokens correct?

@Nir maybe you can help with my question about impersonation?

Hi @bhicks , this change will only affect OAuth2 integrations formerly known as 3LO apps. Do you have a link of the API tokens documentation so that I can confirm whether it will be affected or not?

Hi @anton2 ,
this change will only affect OAuth2 integrations formerly known as 3LO apps. Can you please provide more details about which from of impersonation you are referring to? If it is https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/ , then yeah your app will be affected.
But if it is user impersonation for connect apps like User impersonation for Connect apps then no, your app won’t be affected.

Thanks! We are using impersonation for Connect apps, so we are not affected.

@VincentFiestada I am curious if you have had any feedback or came up with any solution for the parallel execution issue you are describing above?

Our first attempt to migrate to rotating refresh tokens failed, so we are re-assessing the impact of this change and further improve our knowledge on rotating refresh tokens to better understand where things could go wrong. Similar to what you are describing, we have a deployment that allows parallel execution of requests and scales dynamically to more or fewer instances.

With persistent refresh tokens, the refresh token does not change over the lifetime of an OAuth2 installation. Hence, the refresh token can be used across multiple instances and be easily read by many consumers in parallel. However, with rotating refresh tokens the refresh token becomes a shared mutable state, and hence refresh token reads and writes have to be synchronized between consumers.

The RFC on OAuth 2.0 Threat Model and Security Considerations actually contains a note on this issue that reads:

Note: This measure may cause problems in clustered environments,
since usage of the currently valid refresh token must be ensured. In
such an environment, other measures might be more appropriate.

Based on our study on the topic of rotating refresh tokens, OAuth2 is not a simple “one-size-fits-all” solution anymore. As I understand, rotating refresh tokens and PKCE are measures to address security concerns with public OAuth clients (SPAs, desktop/native or mobile applications). However, applying this same measures to private/confidential clients (our use case) does not seem to be always necessary/appropriate and may cause issues as highlighted in the RFC reference above.

@NusratSultana @Nir would you be able to comment if these concerns have been considered when requiring rotating refresh tokens for all OAuth2 clients? If yes, may I ask what is the reasoning?

1 Like

@NusratSultana Integrate Jira with Flurry - Yahoo Developer Network

Hello everyone,

Absolutely agree with the above statements. My team is in a situation where we have just released long awaited by our customers integration for beta testing and it turns out that it won’t work after 30th of November. Great!

Also there is lack of any documentation about settings and configuration, for example leeway and rotating refresh token expiration time. Regarding leeway I saw that it is only 3s in the comments below, but I don’t think this is the best channel to receive such an important details. Also I have tested your API manually in order to understand what is the actual behaviour.

In addition to the above parallel scenarios, there is one more to be handled properly. What will happen if we have not used the refresh token(etc have not updated it) for some period of time and it just have expired? What is the rotating refresh token expiration time?
Update: I saw it is 30 days(in the comments), could you please confirm? Also can access token and rotating refresh token expiration time be set per request? Currently access token expire time is 1h, could it be changed to 1 day for example?

Thank you in advance,

1 Like

Will tokens migrate from persistent to rotating automatically on Nov 30? Or do I need to switch them manually in developer console? I don’t have an access to account (can’t find exact account with some of integrations), so I won’t find/restore account on time probably.
And one more question - can I update expired refresh token for a new one?

@NusratSultana I’ve tested the API last week and it worked as described above - if more than one new refresh tokens are obtained only the first one is valid, if the second-to-last one is exchanged, breach detection will be triggered. Now all returned refresh tokens are valid. Could you please verify? Are there any changes made since then?

NusratSultana Could somebody reference the above questions please? It is quite urgent and critical for our delivery.

A couple of (big) issues I’m seeing:

  1. Neither the announcement, nor the new documentation, mentions the presence of automatic reuse detection. This is a rather large thing to have not be documented at all other than a comment by @NusratSultana pointing to the auth0 site.

  2. This seems to completely break any kind of ci/cd pipeline.

For example: On our codebase, we use GitHub actions to run integration tests on every PR. So we keep a refresh token in a secret that the build job can use. This has been working fine for us for about a year. Now, because of this change, the token becomes invalid the next time the tests run, and we’re unable to run them on another PR until I replace the secret.

Maybe I could somehow make a writable secret on github to write the new token back into it, except for #1 above. Add the reuse detection in, and it becomes a situation where if two developers were to submit two PRs in close proximity to each other, the parallel test runs will make it so all tokens are invalid.

The only solution I can see at the moment is completely disabling our Atlassian integration tests. As I can’t be responsible for manually logging into Atlassian and re-creating the token for every single PR our developers submit just to run the tests.


Hi - can someone from Atlassian pls clarify an issue we’ve come across?

A user has authorized Jira and Confluence cloud for a particular instance. Currently, we hold separate refresh and access tokens for Jira and Confluence.
When we switch on the rotating refresh tokens, this is what happens:

  1. Say the user’s access token for Jira has expired so we renew it. Now we have a NEW refresh and access tokens pair for Jira.
  2. In the same instance, the user’s access token to Confluence is still valid.
  3. But let’s say the user’s access token to Confluence expires. We try to get a new pair of refresh and access tokens (like we did in step 1) but we get status 403.

It looks like the Confluence refresh token is no longer valid after the Jira refresh token is renewed for the same instance.

Is this expected?


1 Like

Greetings, just to double-check, please clarify, if an app does not require offline_access, it still has to update an integration to handle the additional fields returned with a new rotating refresh token, to work after the deprecation window?

Hello - Can someone from Atlassian please clarify the expiration behavior of the refresh tokens.

About a month ago, we updated our app to use rotated refresh tokens (offline_access) and have a job that periodically rotates the refresh token (many times per day). Our assumption was that each new issued refresh token had a 30d expiry. Using this assumption, we would never have to re-initiate the oauth flow as long as we periodically refreshed the token. This has been working fine for exactly 1 month and I just noticed that we are getting a 403 when trying to refresh.

To be clear, we periodically refresh the access/refresh token pair and replace as the new key pair. The expectation was the new refresh token would have an expiry of 30d. The behavior we are seeing is that we get a 403 exactly 1 month after the last initiated oauth flow.

I followed the instructions here: https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/#use-a-refresh-token-to-get-another-access-token-and-refresh-token-pair

If we refresh our refresh token many times per day, why would it suddenly 403 after 30 days?