Azure Logic App Custom Connector failing to authenticate to Jira Cloud API via OAuth 2.0

[anon39683821]

I’ve built an Azure Logic App custom connector which allows me to use Actions in the Jira Cloud API that are not available in the Azure built-in Jira connector.

As my apps were just in dev initially, I used basic auth to authenticate the connector to the Jira Cloud API. All actions in the custom connector worked without issue.

Now I’m moving my apps into Prod I need to change the custom connector authentication to use OAuth 2.0.

I’ve followed the steps in the Jira documentation and can successfully authenticate to the Jira Cloud API via OAuth 2.0 using

1. The authorisation URL provided in my Atlassian developer portal
2. A manually created authorisation URL

However when I enter the exact same details into the Custom Connector OAuth 2.0 Security tab, authorisation to the Jira Cloud API fails with the message ‘This app has not requested any supported Atlassian scope. Check the authorisation URL for your app and ensure that it includes valid scopes’

I’m not sure how relevant this is, but an API Connection is created for the custom connector whenever I attempt authentication.

The fields I’m using in the Custom Connector Security fields are:

• Identity Provider: Generic OAuth 2
• Client id: Copied straight from my Atlassian Dev portal
• Client secret: Copied straight from my Atlassian Dev portal
• Authorization URL: https://auth.atlassian.com/authorize
• Token URL: https://api.atlassian.com/ex/jira/myConfirmedValidCloudid/rest/api/2/project
• Refresh URL: Same as Token URL
• Scope: read%3Ajira-work

For all the above Security fields, I’ve provided the exact same values as those used for the two authentication methods mentioned above, which worked.

I’ve tried the following troubleshooting steps:

1. Adding the scope to the authorisation URL: https://auth.atlassian.com/authorize?scope=write%3Ajira-work
2. Changing the scope in the authorisation URL to another valid scope: https://auth.atlassian.com/authorize?scope=read%3Ajira-work
3. Changing the scope in the Security fields to slightly different formats read%3Ajira-work read:jira-work 'read:jira-work'
4. I’ve also tried changing the scopes directly in the custom connector Swagger file

Again I’m not sure how relevant this is, but when I add the scope to the authorisation URL the Atlassian error message just says ‘something went wrong’ and no API connection is created for the custom connector.

Below is an extract from the Custom Connector’s Swagger file:

securityDefinitions:
oauth2_auth:
 type: oauth2
 flow: accessCode
 authorizationUrl: https://auth.atlassian.com/authorize
 tokenUrl: https://api.atlassian.com/ex/jira/myConfirmedValidCloudid/rest/api/2/project
 scopes: {read%3Ajira-work: read%3Ajira-work}
 security:
 oauth2_auth: [read%3Ajira-work]

Any guidance would be greatly appreciated.

[ibuchanan]

Welcome to the Atlassian developer community, @anon39683821.

I can think of 2 possible problems, both of which center on how external clients would use the authorization URL: https://auth.atlassian.com/authorize.

One possible problem is Azure’s OAuth client assumes some flow other than the authorization code flow (also known as 3LO). If that’s true, then I would expect Azure never redirects you, in the browser, to that URL. And, in that case, we’re stuck because our side only supports the authorization code flow right now. Maybe you could find out which authorization flow it wants, and I can open a feature request.

If you are getting redirected to https://auth.atlassian.com/authorize, please post the full URL here so we can diagnose further. What I suspect is that Azure is not aware of all the query string parameters needed by Atlassian. Specifically, prompt=consent is not part of the OAuth 2.0 standard so I’m not sure how Azure would know to send it. But the error message does complain about scopes, so maybe it is some other parameter mismatch. Hence, full URL would help.

[anon39683821]

Hi @ibuchanan, thanks for the quick response.

I cant see any way of getting the fully formed authorize URL’s that the custom connector is using directly from Azure, but I have been able to capture them using chrome tracing.

The first URL captured (with state and client hashed) is:

https://auth.atlassian.com/login?state=###################&client=################&protocol=oauth2&response_type=code&redirect_uri=https%3A%2F%2Flogic-apis-westus.consent.azure-apim.net%2Fredirect&scope=read%3Ajira-work

• This is with the scope value in the custom connector set to read:jira-work
• I checked the client id in the URL and it is correct

the second url captured (with state hashed) is

https://api.atlassian.com/oauth2/authorize/consent?state=##############

I then get the error message

Thanks

[ibuchanan]

@anon39683821,

You did great!

Small aside about how OAuth works, if sharing the state and client parameters would compromise the flow, then both Atlassian and Azure are doing it wrong. But also, those details don’t matter for troubleshooting. No harm either way.

Your information confirms my 2nd hypothesis. Specifically, prompt=consent is not part of the OAuth 2.0 standard so Azure does not send it.

In the meantime, if you are the only one who needs to authorize, then you may be able to URL hack the flow. Using the Chrome tracking, grab the URL again (each time you try to authorize, the state parameter should be different). Then add &prompt=consent to the URL and retry.

I’m working on filing a bug but I don’t think it will be tracked publicly.

[anon39683821]

Appreciate you taking the time to clarify the situation with the state and client parameters @ibuchanan, I figured if in doubt then best #### it , but good to know for any future issues.

I grabbed a fresh authorisation URL from Chrome tracking and added the &prompt=consent, but still see the same error message. I’m hoping you might have other suggestions for a work around, whilst the bug filing is in the backlog?

[ibuchanan]

@anon39683821,

I seem to have missed an important detail in the URL path and focused on the wrong parameter.

I’m not sure why the URL path is getting written (or maybe rewritten) as https://auth.atlassian.com/login but it should be https://auth.atlassian.com/authorize (which is exactly how you specified it for authorizationUrl).

Then, it turns out there are 2 parameters Azure doesn’t send, that Atlassian needs: &prompt=consent&audience=api.atlassian.com

Let me know if you are able to URL hack that.

As for figuring out a more robust long-term solution, the problem is that Atlassian’s 3LO isn’t “generic”, it’s an interpretation of the token exchange flow (rfc8693). Technically, this is a different authentication type for Azure Logic Apps. I think the right thing to do would be to ask Azure to support Atlassian’s 3LO in the Jira connector, along with whatever other Actions you’ve had to customize.

[anon39683821]

Hi @ibuchanan, kinda good news, using the URL hack you suggested I get one step further

1. The authorisation page loads correctly with the correct scopes selected (see attached).
   

   

2. I click accept and get redirected to:
   https://logic-apis-westus.consent.azure-apim.net/redirect?code=#############&state=%24{hKFo2SBmQnNiNHc3RG10Sk9URU5EYzZlMklmeGN2WXZ6Zlo4d6Fup2NvbnNlbnSjdGlk2SB1ZzFxRnlDdUdCWUE2UnUwdGQ4NGtRMklET2NnQ1RDY6NjaWTZIDZ6T1I5cTdtSzl5SFpMU3M2VDJPaHJRbWdjWVo2TzR5}

I’ve hashed the code just in case I confirmed the code is valid by using it in a call to the endpoint ‘https://auth.atlassian.com/oauth/token’ with my credentials - which did return a valid access token.

Unfortunately the redirected page is blank except for the message:

{“Message”:“The request is invalid.”,“ModelState”:{“consentInfo”:[“No consent server information was associated with this request.”]}}

Any thoughts on a hack to get the redirect url working correctly?

Thanks

[ibuchanan]

@anon39683821,

Sometimes people refer to “the OAuth dance” but this feels like neither party wants to participate!

Now that we’re getting back to the Azure side, I’m much less the authority. That said, I suspect the state parameter is a problem. You should double check that’s not getting mangled along the way.

However, I believe the underlying problem is the state parameter is getting invalidated the first time we hit an error (because that’s how I’d build it). If that’s true, we would need to find a way to suppress the initial redirection, which we might be able to do with browser settings. For Chrome, that’s under Settings → Site Settings → Pop-ups and redirects. I tested for myself and that does prevent Atlassian from redirecting back to my client so I think it should prevent Azure from getting a failure before we URL hack.

[SystemAdministrator]

I am also facing the same issue, and note that this ticket has not been updated for 10d. Has there been any further progress?

[ibuchanan]

@SystemAdministrator welcome to the Atlassian developer community.

There are only possibilities for work-arounds at this time. Have you tried my suggestion above with Chrome settings (or blocking redirects in whatever browser)? Then adjusting the URL with prompt and audience parameters before continuing?

[anon39683821]

Hi @ibuchanan, my apologies for the very delayed response. I’ve tried the workaround suggested but still see the same issue. Microsoft have clearly had this exact OAuth 2.0 flow issue with many other APIs and have added a list of ‘Identity Providers’ to the OAuth 2.0 authentication section of the Custom Connector setup (see image below).

Do you think the best approach to address this would be to have Atlassian and Microsoft reps work together to define ‘Atlassian’ as an Identity Provider option in the OAuth 2.0 section of the Azure Custom Connector?

I’m happy to assist in whatever way I can to help get this addressed.

[ibuchanan]

@anon39683821,

Yes, it would help to work directly with the Logic App team. And I’m just the engineer to do that. In fact, I already work with Microsoft in a general capacity but we’re both big companies with many products. Please DM me with any details that might help lend your voice-of-the-customer to my offer to help them add a new auth provider.