OAuth2.0 for Jira REST API with Azure AD as Identity Provider

Hi All, Jira cloud in my organisation authenticates users via Azure AD SSO. As a first step in Jira
OAuth2.0, I need code(grant type - code flow) for accessing token. However, for retrieving code, I have to authenticate with username & password via Azure AD for progressing with OAuth which become tedious and redundant process for automation script/webservice client. Moreover, I feel purpose of OAuth for an automation script/service client has not been fulfilled.

Wondering, if Atlassian supports client_credentials grant type for communication b/w Jira and a machine? Can someone guide me to resolve this issue?

1 Like

Welcome to the Atlassian developer community @MuthurajArunKumar,

The short answer is yes, but for a very limited set of APIs. Specifically, the client_credentials grant is only available for the builds API, deployments API, development information API, and feature flags API.

You said the process is “tedious and redundant”, which make me wonder if you were aware that user authorization is only needed once if your client can remember a refresh token. Otherwise, can you explain more about why the client_credentials grant type is needed for your scenario?

@ibuchanan Thanks for the suggestion. Refresh token works for our scenario however my team missed it because it was FAQ rather than being part of the authorization flow.

https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/#faq1

@ibuchanan I would like to check a strange behaviour that our team observed while using refresh token API,

Correct Scenario - Working as expected

  1. Make a post call for fetching refresh and access token
  2. Make a post call for Jira REST API using access token
  3. Once access token expires then again make call for new refresh token & access token by sending the refresh token obtained from step 1 response

Wrong Scenario - step 1 & step 2 are same as correct scenario
3. Once access token expires then again I mistakenly made a post call using old refresh token as in step 1 request rather than response which eventually forces me to start from code authorisation flow however, this is not the case for empty or incorrect refresh token where I was able to use refresh token available from step 1 response again to get new refresh and access token.

Error response with code 403
{
“error”: “invalid_grant”,
“error_description”: “Unknown or invalid refresh token.”
}

Can I know, if it is expected behaviour or a bug when I accidentally make a call for using last used refresh token?

1 Like