Forge External Oauth2 doesn't support Atlassian Oauth?

Forge Forge Platform and Tools
,
1

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?

7 Likes
2

Was able to reproduce this with a manifest that includes:

providers:
  auth:
    - key: atlassian
      name: Atlassian
      scopes:
        - 'identity'
      type: oauth2
      clientId: MY_ID
      remotes:
        - atlassian-oauth
      bearerMethod: authorization-header
      actions:
        authorization:
          remote: atlassian-oauth
          path: /authorize
        exchange:
          remote: atlassian-oauth
          path: /token
        revokeToken:
          remote: atlassian-oauth
          path: /token/revoke
        retrieveProfile:
          remote: atlassian-profile
          path: '/users/@me'
          resolvers:
            id: account_id
            displayName: name
remotes:
  - key: atlassian-oauth
    baseUrl: https://auth.atlassian.com/oauth
  - key: atlassian-profile
    baseUrl: https://api.atlassian.com
permissions:
  external:
    fetch:
      backend:
        - 'https://auth.atlassian.com/oauth'
        - 'https://api.atlassian.com'

Running forge deploy --verbose I get:

◀️  GraphQL
Request ID: fbdab3cb70c3d140
Result: {
  "appDeployment": {
    "status": "FAILED",
    "errorDetails": {
      "code": "MANIFEST_VALIDATION_FAILED",
      "message": "Invalid client id v63CTgwHAjWQTiPUqDgqXqurU5asYOMY: Atlassian credentials are not supported in auth providers.",
      "fields": null
    },

@danielwester Can you share an example of an API route you’re intending to use with OAuth2?

3

Im just trying to call /rest/api/3/search to search for Jira issues from a confluence macro.

1 Like
4

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 audience and 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. :man_shrugging:

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):

providers:
  auth:
    - key: atlassian
      actions:
        authorization:
          remote: atlassian-oauth
          path: /authorize?audience=api.atlassian.com&prompt=consent
3 Likes
5

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

For example:

...
actions:
  authorization:
    remote: something
    path: /authorize
    queryParameters:
      prompt: consent

Hope this helps!

2 Likes
6

Hey @danielwester,

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.

3 Likes
7

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?

6 Likes
8

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

2 Likes
9

Greetings folks, Does this mean I cannot use Bitbucket, Opsgenie etc. REST APIs in a Forge JIRA Custom UI app because of the lack of the Atlassian Oauth support?

10

@AbishekMuthian,

Does this mean I cannot use Bitbucket, Opsgenie etc. REST APIs in a Forge JIRA Custom UI app because of the lack of the Atlassian Oauth support?

Not exactly. To my knowledge, Opsgenie does not have OAuth 2 so could not be reached using the external auth module. But that doesn’t rule out API tokens, which both Opsgenie and Bitbucket provide (Bitbucket calls them app tokens). Atlassian is aware this isn’t a great experience and does intend to better support cross-product apps; however, that intention is not really a plan yet so I don’t see any on the near-term horizon that will solve this problem as a Forge feature. In the meantime, your app would have to obtain API tokens.

I realize the cross-product topic is confusing so all questions are welcome. I would ask that folks create new threads to ask those questions. This one is specific to OAuth-based external auth so I’m locking it until/if Atlassian solves for the messaging that @zsims mentioned.