I’m trying to set up a Forge Macro that needs to reach out to other Atlassian Cloud Jira instances using oauth2. I keep getting an error message of
Atlassian credentials are not supported in auth providers.
Does Forge not support Atlassian’s oauth? Is there some type of magical configuration that I need to do in order to do it?
Is there perhaps an example of Forge using Oauth2?
Was able to reproduce this with a manifest that includes:
- key: atlassian
- key: atlassian-oauth
- key: atlassian-profile
forge deploy --verbose I get:
Request ID: fbdab3cb70c3d140
"message": "Invalid client id v63CTgwHAjWQTiPUqDgqXqurU5asYOMY: Atlassian credentials are not supported in auth providers.",
@danielwester Can you share an example of an API route you’re intending to use with OAuth2?
Im just trying to call /rest/api/3/search to search for Jira issues from a confluence macro.
I was wondering where this would go. Based on my understanding of rfc6749, Atlassian’s implementation of authorization code flow is non-standard. Specifically, the
prompt parameters are not in the spec. I have yet to find a good explanation for why those parameters are required when the docs say they only have 1 valid value.
That said, non-standard parameters are rather common in the world of OAuth and there is even an official registry for “bonus” parameters (which does include the ones Atlassian uses but for different authorization flows). Unfortunately, the Atlassian docs don’t have any clues how to handle extra parameters. But I wonder if it would work to put the extra parameters in the authorization path like (partial configuration only):
- key: atlassian
@ibuchanan To your question on how to path extra parameters to the
authorization action, there is an option called
queryParameters that allows you to pass in these additional parameters.
Hope this helps!
This is expected, Forge external authentication does not support Atlassian OAuth today. This is to ensure the scopes presented to the admin at app installation time reflect the scopes the app is ultimately requesting from app users. This restriction may be removed in future as we enhance admin controls around OAuth apps.
I don’t understand this. If I’m using oauth to access a separate oauth app - that doesn’t really use the same scopes. In my case I’m trying to build a confluence app that can access Jira (something that can’t be support by Forge today).
Maybe I’m missing something?
You’re not missing anything. To shed some light on why it’s currently disabled: OAuth apps today don’t go through an installation consent flow by admins as they’re not “installed into” sites.
With Forge user consent and external authentication, there’s not a clear distinction between the app asking for Forge scopes and the regular OAuth consent flow which ends up very confusing for users/admins. It’s very likely the Atlassian OAuth restriction will be removed from external authentication when we’re rolled out finer grain admin controls for OAuth apps or removed Forge user consent per We're removing the allow access prompt for Forge apps