OAuth 2.0 is not enabled for method: GET /rest/api/3/issue/10022

Jira Development Jira Cloud
, ,
1

Hi all. I have successfully authenticated via OAuth2.0 and was successful in creating an issue using /rest/api/3/issue. I am getting a 403 error “OAuth 2.0 is not enabled for method: GET /rest/api/3/issue/10022” when making the GET issue call.

I have the following scopes tied to my application on both sides:

read:application-role:jira read:avatar:jira read:group:jira read:issue:jira write:issue:jira delete:issue:jira read:issue-meta:jira write:attachment:jira read:comment:jira write:comment:jira write:comment.property:jira write:field:jira read:field-configuration:jira read:issue-link:jira write:issue-link:jira read:issue-link-type:jira write:issue-link-type:jira read:issue-type:jira read:issue-security-level:jira read:issue-type-hierarchy:jira read:issue.changelog:jira read:issue.transition:jira read:issue.vote:jira read:user:jira read:project:jira read:project-category:jira read:project.component:jira read:project.property:jira read:project-version:jira read:status:jira read:issue:jira-software read:jira-work write:jira-work manage:jira-webhook read:me read:account offline_access

Any help in diagnosing this would be greatly appreciated.

In general I am finding the scopes documentation misleading. Is anyone else?

Thanks

2

Welcome to the Atlassian developer community @JacksonLisec,

Well, yes, the error message about scopes is misleading. What the docs don’t explain about scopes is how you might get a “scopes” error message when your URL is incorrectly formatted. In your case, there should not be any curly braces {} in your URL. Please do let me know if that solves your problem.

1 Like
3

Excuse my mistake. I was trying the call with and without the curly braces and copy/pasted the wrong error code. Here is the error code from me trying the call without them: OAuth 2.0 is not enabled for method: GET /rest/api/3/issue/10022.

4

@JacksonLisec,

Works for me. I assume you can operate the Developer Console and you did say:

But one way we can confirm the scopes you got instead of just the scopes you asked for is to look at accessible-resources. For example, as a curl (sorry, wrong tool) HTTPie or xhs command:

xhs https://api.atlassian.com/oauth/token/accessible-resources \
    --auth-type bearer \
    --auth "$ACCESS_TOKEN" \
    > accessible_resources.json

The response for my case is:

[
  {
    "id": "c68adbe0-2b09-4add-b08e-eb5797b31bc9",
    "url": "https://devpartisan.atlassian.net",
    "name": "devpartisan",
    "scopes": ["manage:jira-configuration", "read:jira-user", "read:jira-work"],
    "avatarUrl": "https://site-admin-avatar-cdn.prod.public.atl-paas.net/avatars/240/site.png"
  }
]

For this request alone, the client only needs the last one: read:jira-work.

5

Thanks for the detailed response. I am accessing my OAuth2.0 App via a connection configured in an IpaaS called Prismatic—docs linked here I’ll need some time to get a tool set up so that I can make commands like this.

Quick question in the meantime, are the scopes returned by your command above the same scopes that I configure via the permissions tab in the developer console? Can the server have more scopes than is necessary to be requested by the client or do the scopes have to match exactly?

6

@JacksonLisec,

I’ve stumbled across Prismatic before but don’t know much about it. Out of curiosity, do you mind sharing what you’ll wire up to Jira with that?

Good questions.

The OAuth 2.0 spec has more capability than what we’ve implemented. For OAuth 2.0, clients could conceivably “register” a set of maximum scopes and then incrementally request “approved” scopes from users. In an imaginary LinkedIn auth exchange, I might have a client that works with both resumes and posts. When I need the resume, I run an auth flow, and you approve. When I need posts, I run another auth flow, and increment up to both.

In our real context, that means what you put into the developer console can be more than what your client actually has. But, our implementation doesn’t really support the incremental additions. So, for security best practice, it would be best if they are the same. The hard constraint is the “approved” scopes can only be a subset of the “registered” scopes. Otherwise, the auth flow will fail (not the API requests).

Now that I understand that Prismatic is probably managing the OAuth flow for you, you might need a quick way to perform the OAuth 2 flow for yourself. Some months ago, I wrote how you might do that using a utility called oauth2c: