We’re exploring a problem that we’ve heard from several of you - Forge’s external authentication (withProvider()) currently only works in user-invoked contexts via api.asUser(). This means if your app needs to call an external OAuth-protected API from a scheduled trigger, event listener, async event, or any other non-user context, you might be doing this via remotes.
We want to understand how widespread this problem is before we commit to a solution.
If this is an issue for you, we’d love to chat.
A 30-minute interview would help us understand your specific use case and make sure we’re solving for the right scenarios. If this sounds like you, please drop a comment below (or DM me) with a brief description of your use case, and we’ll reach out to schedule a conversation.
I’d be happy to participate. Our use case is very simple: being able to send emails via an OAuth connected email service such as Office365 or Google email API. The admin makes the connection once, and then the connection is used by a scheduled trigger to send emails.
Our use case is simple: we need support for Forge OAuth providers in Forge Remote.
For performance reasons, our apps store 3rd party API responses in cache. Forge does not support caching, so we use Forge Remote. We call the OAuth provider from Forge Remote, so we need access to the OAuth tokens from Forge Remote.
This can either be solve by an additional API request to retrieve the access_token, or by providing the access_token in the context of a forge function/trigger where we pass the token to the Forge Remote using invokeRemote.
We do not need access to the refresh token if Atlassian ensures that the access_token is valid.
We’d love to chat to the current person in charge of this.
I’ve talked to a lot of your predecessors about getting the asApp version of this working on Forge over the years, but it has always been kicked further down the road.
If you’re able to start work on this quickly, we may be able to start our journey to migrate our apps to Forge soon.
Thank you for your replies. @MattMuschol@david I have DMed you for further steps. @remie@JannickJoosten curious about your comments. Are you saying that you want out-of-box support for external OAuth inside Forge remotes? Is the main reason that you cannot move away from remotes due to caching dependency on your end and don’t want to manage tokens by yourself?
I can not speak for Remie ofcourse, so maybe he has other ideas.
For us we perform all our compute inside a Forge Remote. Forge OAuth providers is the platforms way of doing OAuth so that implementation will feel better/smoother to users than implementing it ourselves. Having then access to the provider inside a Remote gives us the best of both.
And having it available inside a Remote allows us to have a hybrid solution where we run some stuff in Forge Functions, but also rely on Remote’s for stuff that can not be ran inside Forge Functions/Containers
We would love to use the Forge OAuth providers, mainly because they offer a better user experience for our customers. In addition, it will allow us to remove external egress permissions from our manifest.
The reason we cannot use Forge OAuth providers right now is because we need to call the 3rd party API from the Forge Remote.
If the Forge OAuth provider is available from the Forge remote, we would definitely use it.
@RashiChandola we have a private app pulls in metadata from other services and platforms and we currently implement our own OAuth client and store secret in Forge secret store. Would love to offload everything to Forge. Happy to chat.
