OAuth 2 Authentication, forbidden error?


I am developing a OAuth 2 integration to be able to read our Cloud Instance of Jira so I can pull data on issues.

I have configured the application and have authentication working. However I have a weird bug. If I use the the read user identity scope, all works and I get back a 200 ok response on my call back URL.

However, if I then include the Jira Work read scope, I get a 403 forbidden response, even though I give the permission at the grant access screen.

I am the site administrator, I can see the app in the Connected App’s page. So I am dumb founded why using a Jira Scope fails, even when I have enabled the permission in the app config and the user grants it at the time of authentication.

Any suggestions appreciated, as this is driving me mad :frowning:



Could you provide us with the URLs you are trying to use, paired with these scopes you mentioned?


Here the auth request URL, I removed the Client ID.


As I said, if I remove the read:jira-work scope it works fine.

Therefore I dont get why I get a 403 forbidden response with the Jira Scope.

A 401 unauthorized I would understand.


@ibuchanan are you able to provide any insight as to why i would be getting a 403 Forbidden response?


@ibuchanan I have tried deleting the app and recreating it.

Still have the same problem, so really at a road block right now as to why I can’t access the JIRA API’s

Any help would be appreciated.


I’m just starting with RESP APIs, but, as far as I know, those scopes are working.
I’m using them on my .Net Core app, and I can get info from Jira with no problems.

So, the only thing I can think is that you have something wrong in your Jira Configuration with authorization or permissions for the user that is triying to connect. Or maybe you forgot to add read:jira-work to permissions on your app configuration in developer.atlassian.com portal.

I think the problem is your redirect_uri. It must be HTTPS and it must match what was provided in the developer console. Per Atlassian’s OAuth 2.0 documentation:

Enter the Callback URL . Set this to any URL that is accessible by the app. When you implement OAuth 2.0 (3LO) in your app (see next section), the redirect_uri must match this URL.

@ibuchanan Why does the call work for the identity API when the scope is just read:me?

I only have to change the scope to read:me and it works, as soon as I add read:jira-work it fails.

@CarlosALpezOrtn the account I am using is a Site Admin, there are no more permissions this account can have.

It doesn’t matter if you’re an admin or just a user, the app permissions are that, app permissions.
Just go to developer.atlassian.com, go to developer console (in your avatar when connected), select your app, go to permissions, Jira API, configuration button, and check again if you have the read:jira-work scope checked the same way as read:jira-user.

You HAD to check them manually to work, they’re unchecked by default.


I have no idea why read:me works for you. But I cannot get any variation to work with an http URL, including just read:me.

@ibuchanan thats interesting and the thing that completely throws me.

I will create a cert today for local host and try that out.

@CarlosALpezOrtn thanks for the response, yes I have given the app permissions, its how I initial got the scope, as once you assign the permission and save them, it provide authorisation URL’s with the scope and callback url encoded, ready to use.

@ibuchanan https callback was not the problem.

I have installed a cert and have gotten HTTPS working for localhost.

I updated the callback in the app authentication settings to https.

Same problem, when the scope is read:me, authentication works.

When I change the scope to read:jira-work, I get a 403 forbidden. This is driving me crazy, I would be happy with the read:me scope didnt work, then I would be able to assume theres some problem with my code.

But it does work, so I am assuming theres a problem with our instance of Jira, that is causing the authentication process to return a 403 when requesting the read:jira-work scope.

Problem is, I can read every document and for the life of me I can not find a permission or setting thats not set correctly to allow access.

Just to be clear: using read:jira-user alone, all works fine, but if you add read:jira-work, then nothing works? Or just the read:jira-work part is failing? Your app do something with only read:jira-works? Did you tried with the new scopes?

If one scope works, but not the other, I only can think it’s a permissions problem. I would ask you to check the forbidden response deeper, event try using Postman to discard code problems and get more info about the 403 error.

@CarlosALpezOrtn thanks for providing another perspective.

Yes, the read:me scope works and no other scopes work. I tried the new fine grained scopes as well, all the same, a 403 forbidden.

P.S. Not sure Postman will work, as you need to authenticate and accept the scopes in the authentication screen. I think I might use a proxy in stead as then I can see the raw responses.

Ok, thanks to @CarlosALpezOrtn for reminding me to look at the actually HTTP responses.

The problem would appear to be a Next JS, Next Auth error.

This is the success header when Atlassian redirects back to my localhost. Below in a second post as I can only post one image per post, is the failed header, as you can see, they are both exactly the same. Therefore the problem lies within Next JS Auth library, which I will now debug to try and find the issue.

On another note, you can use localhost without HTTPs for development, obviously, use HTTPS for production.


Just for completeness and in case someone else runs into this issue.

I have resolved the problem and are now able to call the JIRA API.

The problem was the Next JS Auth package and how you I initialized the library. In the constructor you need to provide the scopes, so I was providing read:me read:jira-work and this would fail.

If you initialize with just read:jira-work, yet in the authorisation URL you still request read:me and read:jira-work, it succeeds. Long story short, problem solved and it was me all along :frowning:

Thanks to @ibuchanan and @CarlosALpezOrtn for your suggestions and help.


1 Like