Forge Remote access to tokens anytime is now in Preview

Forge Forge Platform and Tools
, ,
1

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

Connect frameworks, Connect Express and Connect Spring Boot have been updated to support this functionality, and the Forge Remote reference apps will be updated shortly with examples of how to implement.

To learn more, please have a look at our documentation here

As always, your insights are incredibly valuable to us, so please don’t hesitate to ask questions and share feedback. We’d love to hear from you!

4 Likes
2

Hi @DanielReed,

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.

Thanks,
Artem

3 Likes
3

Hey @DanielReed,

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?

1 Like
4

That is true, unless your app has a web trigger that you hit to essentially give yourself a new token.

This would only be necessary if your remote missed more than three scheduled triggers.

We would hope that these, combined, would be enough for every apps use case, so please let us know if it is not.

1 Like
5

I believe that you should be watching: [FRGE-493] - Ecosystem Jira

The good news is that this work is roadmapped and we should have more news for you sometime next quarter.

6

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.

1 Like