We are pleased to announce that Forge Remote Access to tokens anytime, is now in Preview.
Extending oAuth token life
We understand that there are various use cases that require communication with Atlassian APIs from a remote back end without relying on a user interaction or product event. For example, you might need to trigger actions based on webhooks from other systems or utilise your own external UI.
In order to solve this problem, we have extended the oAuth access token max TTL from 1 hour to 4 hours. As usual, the exp claim in the payload represents the expiration time.
Developers can configure scheduled triggers to periodically deliver new access tokens with a longer expiry time of 4 hours. These tokens can then be cached for later use to authenticate requests with Atlassian APIs.
This is a very useful feature, but it seems that only appSystemToken can be refreshed this way. Is that correct?
Our Connect app heavily relies on user-impersonated access (appUserToken), and we won’t be able to move to Forge unless we can obtain user tokens without relying on a user interaction or product event.
Could you clarify if this is the result of RFC-34? Or, is that treated separately?
Developers can configure scheduled triggers to periodically deliver new access tokens with a longer expiry time of 4 hours. These tokens can then be cached for later use to authenticate requests with Atlassian APIs.
The above mitigates the issue of a remote not having access to Forge APIs at any time. However, if the remote does not have a cached access token for some reason, it still cannot get a new token on its own and has to wait for the subsequent scheduled trigger request. Is that correct, or do I miss something?
Thanks for the clarification, @rmassaioli. I may not speak for everyone here, but this solution seems fine to me. I appreciate its simplicity, considering the complicated flows in the RFC.
I have been working on an experimental implementation that uses the system access token to call the Forge Storage API.
One issue I found quite tricky is that the Forge Storage API requires the contextARI, which looks something like the following: ari:cloud:confluence::site/1234.
The docs suggest assembling this context ARI with the context.cloudId parameter obtained from the Forge Invocation Token payload. Unfortunately, this does not work for system access tokens - they have no such payload.
With the feature described in this post, we may use system access tokens outside the context of a Forge Remote request. I can find a context ARI in the system access token’s audience (aud) claim array.
Do you see any issue with parsing the context ARI from the system access token aud claim? i.e., use a JWT library, parse the aud claims, and find the one that starts with ari:cloud:confluence::site/ or ``ari:cloud:jira::site/`
Can we assume that there is only ever exactly one context ARI in the aud claim and that it is always present? Otherwise, this would not work.
Is there any other/better way to get the context ARI outside of the Forge Remote request context
If the above is the general recommended practice, it would be good to mention this in the docs.
There’s an improvement request internally to remove the need for passing in the contextAri to Storage APIs from remote invocations. I have created a public suggestion to track this work (see https://jira.atlassian.com/browse/ECO-556) and I’m optimistic we can get it scheduled in the near future.
Sorry there’s no easy answer here - we appreciate you taking the time to flag this issue, as it’s given us the ability to bump the priority of fixing this limitation.
It’s probably “OK-ish” for you to use the aud claim in the short term (as there’s no alternative), but only if you pinky promise to remove your dependency on it once ECO-556 is fixed.
The suggestion to remove the contextAri requirement for Forge Remote requests to the Storage API would be a welcome change. It’s been a bit confusing to work with as it does not appear anywhere else when working with Connect on Forge/Forge Remote. The JWT context payload we are supposed to read the contextAri from is a loosely defined JSON payload (depending on the invocation context), which makes it not that easy to work with.
I might do some testing with the current setup, but as advised, I will refrain from releasing it until this is addressed.
Developers can configure scheduled triggers to periodically deliver new access tokens
I am working on an implementing a connect on forge app which uses these tokens to access forge storage. Currently I am using a scheduled trigger and a webtrigger which triggers a forge function that calls invokeRemote to send a new token to our remote connect REST API.
The system oauth token sent in this instance does have a 4hr expiry as mentioned above, but I have noticed that it is actually sending the same token right up until it is expired. This is not really ideal as we want to ensure that it is always going to be valid with a buffer period before expiry. Is this the expected behaviour since the above wording implies that you would be able to get new token each time?
You’re right! The token wont refresh every hour, however, it will refresh if the minimum duration is less than 2 hours.
If this isn’t the behaviour you’re seeing, please log a bug with support and I’ll get the team to investigate, and if this isn’t the behaviour you’d expect to see, please let me know.
Hi @MichaelHenrysTechTim@richard.white, the access tokens should be valid for a minimum of 2 hours when it reaches your remote, it seems like this is not happening for you. Are you able to spin up another thread with more context or raise a support ticket if there is sensitive information involved so we can look further into it?
