Refresh token get invalid after few hours as per document it should retain till 90 days.

[AppFlow]

We have created 5 applications and configured in our application. Each flow has separate app along with different access and refresh token pair. When we start use flow it works for few hours it means refresh token able to generate new access token for 7 to 8 hours as access token expires in one hour but after that refresh token itself became invalid and our flow started failing.

We are getting this error while invoke refresh token api -

Error due to: Forbidden. Details: {""error"":""unauthorized_client"",""error_description"":""refresh_token is invalid""}

As per our understanding if new token request trigger with same application existing refresh token become invalid to overcome this behavior we have created dedicated app with expectation each flow run independently and do not impact on each other tokens. We were expecting this will help but not working this approach.

We are looking for solution which can retain refresh token long last at least as mentioned in document for 90 days or if possible more than that we would like to know if possible.

Currently this issue breaking down our system every day.

Looking for support and suggestion how to overcome this issue.

Thank you in advance.

[Brian Kirwa]

You're welcome!

You don’t necessarily need to purchase new paid user accounts. You can create dedicated service accounts (standard users, not admins) for each app or flow. Each of these accounts should have just enough permissions to perform the tasks required by that specific app. This helps isolate tokens and avoids cross-app token invalidation

If you're using a user directory like Azure AD like we do, managing these service accounts centrally can help you stay organized and secure

Thanks again and feel free to mark it complete

[Brian Kirwa]

Hi @AppFlow ,

This is a common issue when working with OAuth 2.0 in the Atlassian ecosystem, especially when using multiple apps or flows concurrently

What’s happening:
Atlassian only allows one valid refresh token per client-user pair. When you use a refresh token to get a new access token, the old refresh token is immediately invalidated. If another process or app tries to reuse the old one, it will fail with "refresh_token is invalid"

What you tried:
Creating separate apps for each flow makes sense. But if the same user account authorizes more than one app or flow, or if refresh tokens are shared or requested simultaneously, they can still interfere.

How to fix it:

1. One refresh token per user-app pair:
   Make sure each flow uses a unique combination of app and user. Consider using service accounts if the flows are automated.

2. Avoid concurrent refresh calls:
   If two systems try to refresh at the same time, one token will be invalidated. Implement locking, queuing, or a shared cache to control refresh timing.

3. Update your refresh token each time:
   After calling the refresh endpoint, store the new refresh token that is returned. The old one becomes invalid immediately.

4. Use a central token service:
   Instead of letting each service manage refresh tokens, create a single token manager service that handles all refresh logic and shares access tokens with the rest of your system.

Important of all:
Refresh tokens can last up to 90 days only if they are not used. Once used, they rotate and the old one expires.

Let me know if you want help setting up the token manager or refresh logic

[AppFlow]

Thank you for quick response. 

1. One refresh token per user-app pair:
   Make sure each flow uses a unique combination of app and user. Consider using service accounts if the flows are automated.

   Ans. Yes we have 5 app with same account, so is this impacting here ? Do we need separate account for each app ?

2. Avoid concurrent refresh calls:
   If two systems try to refresh at the same time, one token will be invalidated. Implement locking, queuing, or a shared cache to control refresh timing.

   Ans. Each flow has separate app so believe this is not happening here. Could you share document if available ?

3. Update your refresh token each time:

   After calling the refresh endpoint, store the new refresh token that is returned. The old one becomes invalid immediately.
   1. Ans. Yes this is happening, we have automated this workflow. It is replacing new refresh token and access token. But after 7-8 hours refresh token stop working. 

4. Use a central token service:
   Instead of letting each service manage refresh tokens, create a single token manager service that handles all refresh logic and shares access tokens with the rest of your system.

   1. Ans. Could  you please provide more detail on this ? 

Appreciated for sharing detail.

[Brian Kirwa]

@AppFlow Good way of answering questions!!

Yes we have 5 apps with the same account, so is this impacting here?

Yes, that could be the root of the issue. Even though you’re using different apps, if they all use the same Atlassian user account, the refresh tokens can conflict. It's best to use a separate user account per app, especially if each flow is running independently. Creating dedicated service users for each app usually helps avoid this problem

Each flow has a separate app so believe this is not happening here. Could you share a document if available?

There’s no specific Atlassian doc for this behavior, but it follows standard OAuth2 with rotating refresh tokens meaning once you use a refresh token, it becomes invalid and is replaced with a new one. If multiple systems are trying to refresh at the same time, only one token will remain valid. Even if apps are separate, using the same user can still cause this behavior- but check this one not atlassian related though--draft-ietf-oauth-v2-1-10

Yes this is happening, we have automated this workflow. It is replacing the refresh token and access token. But after 7–8 hours, the refresh token stops working

If refresh is automated and tokens are properly updated, then it's likely due to the same user being used across apps or a missed token update in one of the steps. You could log the last valid refresh token and when it fails, compare with what was stored in your system that might show if an older token was accidentally reused

Could you please provide more detail on this?

The idea of a token manager is to have one service that handles all the token logic. This service keeps the current access/refresh token pair, does the refreshing when needed, and other parts of your system simply ask it for the current valid access token. This way, only one place handles refresh logic and the risk of token mismatch or conflict goes down

[AppFlow]

Thank you for clarification Brian Kirwa

Regarding "separate user account per app" 

Do  we need to procure new user account similar we have this or within this user account we can add more user and configure ?