I am implementing a custom OAuth flow on Forge (not using provider). On our Connect app, we are using window.open to redirect the user to the auth server. This ensures that the tab opened by window.open has the opener reference set and allows us to make a cross-origin postMessage to the originating Connect iFrame upon completion of the OAuth flow.
Unfortunately, on Forge, calling router.open does not carry the originating window reference through to the new tab. This is a problem because it does not allow us to safely signal OAuth flow completion to the originating Forge Custom UI iframe.
Curious if this is something that can be fixed/added?
As a workaround, we could implement a polling mechanism on the Forge iFrame that triggers a view update once it detects completion (success or error) of the OAuth flow. However, this is causing unnecessary traffic (depending on the polling interval) and will likely not feel very responsive to the user.
Due to security reasons, this is not something that we can support with Forge Custom UI. Passing the opener reference can allow malicious apps/sites to redirect the iframe to another URL (among other things).
Is there any specific reason why you are not using the OAuth provider? Is there something missing there to support your use case?
Yes, there are two main reasons why we cannot use Forge OAuth providers:
Providers are always tied to a particular Jira user and,
you can only have one connection per user and provider.
We have made several Atlassians aware of those limitations. The conclusion from previous discussions and Atlassian feedback is that we need to come up with our OAuth implementation.
For some more context, we are trying to re-implement our Connect app on Forge. For the re-write we do not want to make any changes to the way the app works. In our Connect app the OAuth connection is set up in the project settings and tied to that particular project. Therefore we have potentially multiple OAuth connections that are not tied to any particular user.
