Action required: Update scopes for Forge and OAuth 2.0 (3LO) apps

Hi @RandySwift,

This is because offline_access is a scope defined in Auth0, not a granular or deprecated scope.

Hi @michelegranato,

For a Forge app, you should be able to update the scopes in your manifest to Granular Scopes by removing the deprecated scopes in the manifest and running forge lint --fix. Feel free to reach out to us if this isn’t the case/doesn’t work.


@danielwester Thanks for bringing this up . You should be able to see NONE for the rest-api’s when there are no scopes .

Hi @ScottLeggett thanks for your feedback and your support to the work we are undertaking to provide more app security to our mutual customers.
At the moment there are no concrete plans on granular REST APIs but it is something that we are looking into so interesting to have this input. What is your view on more granular APIs as a potential next step for Granular Scopes?

Hi @RandySwift, I now understand your particular use case - even when you use the new scopes to update your app the partner side of the app is using the old scopes in the authorization flow. The app requires to be updated for the flow to work again.
If this is correct we would suggest the following workaround: end users to change the URL in the authorization flow directly in the browser address bar. Would that be feasible for you? We will provide an update if anything changes on our end

Hi @Vishnu, the issue with read:issue.transition:jira scope should be fixed now. :slight_smile:


@RandySwift @danielwester please note following fix we have now deployed. This should unblock you with new app development. My sincere apologies for any disruptions this has caused you Atlassian Developer Status - App partners and customers could not create new 3LO app with deprecated scopes

1 Like

For my specific use-case I’d like to have an API to determine if an issue is “valid” (e.g. it exists, and is visible to the user). The most obvious API to use, Get Issue, requires 9 scopes. Ideally there would be some API to get very limited Issue data that only requires read:issue:jira.

We’re seeing some strange behaviour with comment_created webhook events, is it possible the documentation doesn’t list all the required granular scopes for receiving such events?

I started a separate topic with more details: Webhook won’t emit, incomplete docs for comment_created granular permissions?

@AnnaTalebBendiab @JuliaDaehne

I am trying to update two calls to the following Confluence Cloud REST API endpoints:

  • GET /wiki/rest/api/space
  • POST /wiki/rest/api/content

I managed to update my app’s scopes and add the required new ones (read:content-details:confluence and write:content:confluence), according to the API docs.
Both show a huge list of possible operations on the re-auth page, but I only need to get the list of spaces and create pages.

For example, the classic read:confluence-space.summary scope seems way more granular for me than read:content-details:confluence. Also, there is a write:page:confluence scope that could be matched with the "type": "page" property of the request body, only granting access for creating pages instead of all types of content.

Is there any chance that these scopes can be changed before the deprecation window ends?

@MarcoAraujoNeves in the light of the comments received on the granular scopes rolled out we have stopped the deprecation. We will share more details shortly

What does this mean? Should we be rolling back to the original scopes if we’ve already updated things?

When is shortly?



@JuliaDaehne Is there any chance to let use Jira Software REST APIs from OAuth2 apps? Currently jira-software scopes are present only in the new granular setup, so it would be convenient to get a way to use it via some “new legacy” scope.

Hi @danielwester if you have enrolled to the new scopes already you do not have to roll back.

@Grzegorz.Tanczyk yes that’s a good point and we are currently discussing how to deal with Jira Software scopes.

1 Like

Hi Team,

For this issue …

We found that the wrong cloudId was being used. Once the user has authorised the app, you need to use the to get all the sites that the user has authorised your app for. Search the list for the same URL and then use the cloudId (id in the list).

The documentation is

Hope this helps.

1 Like

It’s been a month or so - can we get an understanding of what’s going on and what the next steps are? If this is truly on hold - can we get the documentation updated since it is causing confusion?

For example

Hi @danielwester we are currently working on the doc updates. Apologies for taking so long. This should hopefully be done by latest next week. In the meantime we have started to review the granular scopes and way forward

Hi, I posted about an issue I had while migrating to the new scopes about a month ago here, but wanted to post on this thread as well since I haven’t gotten any feedback there.

As I understand it, the legacy scopes will no longer be deprecated, but my team and I would still like to use more granular scopes if possible.

---- begin original message ----

I’m in the process of updating my app to use the new granular scopes for JIRA OAuth. I’ve added the scopes in my code and in the developer console, but when I attempt to GET from /rest/api/3/project, I receive the below error message:

“Access to the resource was denied due to missing scope grants. Your app was granted the following scopes: [read:field:jira, offline_access, read:issue:jira, read:label:jira, read:project:jira , read:project.component:jira].

The resource can be accessed by having one of these groups of:

  • current scopes: [read:issue-type-hierarchy:jira, read:user:jira, read:application-role:jira, read:avatar:jira, read:issue-type:jira, read:project:jira ,, read:project-category:jira, read:project.component:jira, read:group:jira, read:project-version:jira]
  • deprecated scopes: [read:jira-work]”

As you can see in bold, the message is simultaneously telling me that I have the needed scope and that I can’t access the resource because I don’t have the needed scope.

I know that the endpoint I’m using is deprecated, but I’ve also tried with the newer /rest/api/3/project/search endpoint and get the same result. I’ve also hit the same endpoint in my browser and received a 200 response.

Has anyone else run into this? Am I missing something?




We are using Jira Cloud Platform. When I went to look into the permissions/scopes we are using, there weren’t any of these new granular ones that are included in the update.
We are already using the recommended classic scopes

  • read:jira-user
  • read:jira-work

We are also using report-accounts which seems to be different from the REST API, so I was wondering if it is necessary for us to update at all?