We receive the Forge system token (X-Forge-OAuth-System) in two different flows:
- From Custom UI → Resolver → Remote backend
- From a Scheduled Trigger
The tokens received from these two flows are different, which is fine. Additionally, each flow tends to return a same token until they are refreshed, which is also fine.
However, the refresh behaviour differs between the two from what i’ve observed:
-
In the Scheduled Trigger, a new token is issued when the current token has less than ~2 hours of validity remaining.
-
In the Resolver flow, the token is not refreshed until it is very close to expiry (around ~1 minute remaining).
Problem
This mismatch causes an issue where:
-
A relatively fresh token (with longer validity) obtained via the scheduled trigger is stored.
-
Later, when a user interacts with the app, the resolver flow provides a near-expiry token.
-
This near-expiry token overwrites the previously stored token, leading to 401 errors when used shortly after.
Question
What is the recommended approach to handle this scenario? Specifically, how can we prevent a near-expiry token (from the resolver flow) from replacing a token with a longer remaining validity (from the scheduled trigger)?
Is it fine if we decode the tokens and compare the exp field ? Is it reliable ? because the document says OAuth tokens must be treated as opaque : https://developer.atlassian.com/platform/forge/remote/essentials/#oauth-tokens-must-be-treated-as-opaque