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

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,
Desislava

1 Like

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

4 Likes

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?

Thanks,
Fatmeh

3 Likes

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?

1 Like

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?

Thanks!
-kevin

4 Likes

Hey Kevin, check out the comment above about “automatic reuse prevention”. It is possible that is what you are seeing.

Hi, I have the same question as @DmytroMakhun, if my app doesn’t use offline_access scope at all, do I need to take any action?

This is obviously not an official answer, but if you do not use the offline_access scope, then you also don’t use refresh tokens – so I don’t think this change affects you.

1 Like

Hi Kevin,
Every new rotating refresh token has 30 day expiry. Your auth client that is associated with your app can have different refresh tokens depending on the logged in user. So, the 30 day expiry is per user per rotating refresh token. My assumption is you are refreshing the refresh token for the current logged in user. There might be other refresh tokens stored in your database for users who has not logged in past month and causing the 403.

HI @FatmehShuman ,

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

Thanks.

Hey @NusratSultana ,

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:

  1. User completes OAuth2 flow, which issues the first (access, refresh) token pair on day 1
  2. 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.
  3. 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.

Thanks for your help and any insight here!
-kevin

I don’t think so. See my latest comment.

tl;dr We proactively refresh many times per day using a cron and are getting 401 errors 30 days after the user originally completes the OAuth2 flow.

Hello,
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.
thanks,
James

Hello,

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?

Thanks!
-kevin

1 Like

Hi @JamesSmithHakkiri ,
Apps that utilize the OAuth 2.0 3LO integrations that are configured via the usage of application links are out of scope of this change. Thanks.

1 Like

Hi @DmytroMakhun ,
If your app is not using offline_access scope, then you are not using refresh tokens. So this change won’t affect you.

1 Like