How to map API token scopes with API

[Sergii Pechenizkyi]

I have a small script that aims to group issues into a released version. I verified that it works with an unscoped token, and I wish to improve it by using a limited scope, as I plan to integrate it into a CI script.

Unfortunately, after a few attempts, I can't figure out which scope I need to use to execute the API calls. I wish there were a more straightforward way to access documentation that includes a list of API methods and the corresponding token scopes they require.

Here is what I want to run with the Python JIRA wrapper:

jira = JIRA(server="https://custom.atlassian.net", basic_auth=(jira_username, jira_api_token))
issues = jira.search_issues(SEARCH_QUERY, maxResults=False)
version = jira.create_version(name=get_new_jira_version_name(), project="PAX", description="")

for issue in issues:
  issue.update(fields=dict(fixVersions=[{"id": version.id}]))
  jira.transition_issue(issue, '131')

I have tried the following scopes:

• delete:project-version:jira
• read:project-version:jira
• write:project-version:jira
• read:jira-work
• write:jira-work

However, I still receive the following error message:

{"errorMessages":["Field 'fixVersion' does not exist or this field cannot be viewed by anonymous users.","The value 'PAX' does not exist for the field 'project'."],"warningMessages":[]}

[Michael Altmann]

Recently ran into the same issue. I presume it doesn't work because the scopes are only for OAuth 2.0 authentication and wont work with basic auth.

As unscoped API tokens are already deprecated i wonder if basic auth for API calls will also be deprecated in favor of only supporting OAuth 2.0 authentication in the future.

[shaozihao]

Me too. But I find out using basic authentication with OAuth 2.0 does work. I create API Token with scopes and call the request to GET /rest/api/3/issue/{issueIdOrKey}. It worked. The URL is https://api.atlassian.com/ex/jira/{cloudid}/{api}. Cloudid is your site cloudid and you can get it from https://{yourdomain}.atlassian.net/_edge/tenant_info. Api is the url, like rest/api/3/issue/{issueIdOrKey}. Then go with Basic authentication and username is your email address and the password is your API Token. If the http response code is 401, it means the API Token scopes does not match. If the http response code is 404, it means something wrong about the http request structure.

Also, I find out the API Token without scopes works when the url is the same as the example url which is shown in the api document.

Hope it can help you

[SvenH]

Hi @shaozihao

where does this use oauth2? I can only see here that you use the api directly instead of through python.

I have tested thoroughly here as well with python and I'm having the same problem as @Sergii Pechenizkyi - non-scoped tokens work fine with basic_auth whereas scoped ones don't.

We have been migrated into the cloud recently and I have to cope with a situation where a scoped token on a dedicated on-premise instance with read-only for jira now has to be replaced with a non-scoped full permission token that has all permissions that I have for all Atlassian apps that we have.

This sounds like going backwards 20 years...

Did anyone manage to get python to work with oauth properly in a CI/pipeline environment? 

[Daniel Lamando]

The steps from @shaozihao works for me.

It seems like the URLs that we expect to use:

https://<vanity-name>.atlassian.net/rest/...

simply do not accept scoped personal API tokens with 'Basic' auth. An unscoped token would work, but a scoped token is quietly ignored and results in the anonymous response.

Once I switched to the internal URLs (using the ID from the "tenant_info"):

https://api.atlassian.com/ex/jira/<tenant-uuid>/rest/...

then the scoped API tokens began working with Basic auth. And any missing scope for a particular API was reported properly as an error.

[Izabela França]

Hello, @Sergii Pechenizkyi ! Welcome to the Atlassian Community.

I saw that you tried granular scopes such as delete:project-version:jira , read:project-version:jira and write:project-version:jira. It is just a guess, but have you tried using the classic manage:jira-project scope? I found some information in this Update version.

It is just a guess, I'm interested to hear what others have to say!