Forge External Oauth2 doesn't support Atlassian Oauth?

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?

5 Likes

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?

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

1 Like

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

@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

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

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?

4 Likes

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