Is there an app specific URL for a forge webtrigger?

Forge
, , ,
1

Hi,

the following scenario. When trying to call an external 3rd party app via OAuth from a forge app, the call needs to have a callback URL which matches the callback URL from the OAuth app registration in the 3rd party app. However, since a forge app is installed in an Atlassian tenant, I think each app installation has a different URL, right?

For example:

Let’s say I register a Facebook app. This Facebook app has a client id, client secret and a callback URL. Now I install a forge app containing a webtrigger and a project page in tenant A with the site URL tenantA.atlassian.com and in tenant B with site URL tenantB.atlassian.com. Is there an app specific URL which could be used as the callback URL in the Facebook app registration?
Because after logging into Facebook and authorization the OAuth flows sends a token to the callback URL registered in the Facebook app registration, but if the webtrigger has a different URL in every tenant, than there is no real way of doing this, right?

Hope its clear what I’m trying to achieve, just let a forge app communicate with a 3rd party app via OAuth. #codegeist

Thank you and kind regards
Sven

1 Like
2

You can always get your webhook via webTrigger.getUrl(moduleKey: string): Promise<string>;
The output is a full URL for the Webhook. This URL you can use as the callback url.

When you want to use the same token or callback for both apps, it is not possibly.
https://developer.atlassian.com/platform/forge/runtime-reference/web-trigger-api/#webtrigger-geturl

3

Just to be clear, If I install my App into 2 different tenants, I can’t use this webTrigger.getUrl(moduleKey: string) url as the callback Url?

4

A bit late but just posting my thoughts here because I am trying to solve the same problem:

Simply using webTrigger.getUrl(moduleKey: string) as a callback URL will not work in almost all OAuth2 cases because the web trigger URL differs from installation to installation and typically needs to be registered upfront with the OAuth2 service.

I am currently building a solution for this by encoding the web trigger URL in a JWT claim. The JWT is then used as the OAuth2 state parameter. Additionally, there will be a tiny external redirect service that gets called by the authorization server (AS) via a static callback URL. The redirect service will verify the state parameter JWT from the AS. If the JWT is valid, it will read the web trigger claim and redirect the request to the web trigger URL (together with a newly signed JWT that includes a code claim).

This only describes the flow conceptually. Exact security requirements are yet to be defined.