URGENT! API accessible-resources endpoint returns sites/resources that are not permitted by the user

Jira Development Jira Cloud
, ,
1

In our system user authorizes a specific JIRA site/resource so that using the API we create an issue.

We use OAuth for authorization.

The problem is that https://api.atlassian.com/oauth/token/accessible-resources endpoint returns all existing sites/resources regardless what user permitted.

Here is documentation - https://developer.atlassian.com/cloud/confluence/oauth-2-3lo-apps/

We want to get specifically the resource that user authorized so that we create ticket/issue in this site only.

This is very urgent! Please let us know how can we fix this issue.

3 Likes
2

@GarnikGiloyan,

While I can appreciate you may have a sense of urgency but what you described is how OAuth 2 has worked since launch. And I admit that others have asked for the same thing, but there isn’t a simple “fix” for this. From what I can tell, the expectation is that clients are expected to have their own “routing” to a Jira site and not depend on only the latest consent.

(Edit to more directly address the subject and the following)

The problem is that https://api.atlassian.com/oauth/token/accessible-resources endpoint returns all existing sites/resources regardless what user permitted.

If this is true, we have a bug. However, I cannot confirm this. I can only see accessible resources for which I have approved the app. It can be multiple, but it is only those authorized by me.

1 Like
3

Thank you for your message.

Can you please share the code you are using?

We use the following code

async accessibleResources(refreshToken: string) {
const tokenObject = await this.getToken(refreshToken);
if (tokenObject.access_token) {
const result = await this.httpService.axiosRef.get(
“https://api.atlassian.com/oauth/token/accessible-resources”,
{
headers: {
Authorization: Bearer ${tokenObject.access_token},
},
}
);
if (result.data) {
return result.data;
}
}
}

Maybe there is a bug in the API version we use?

Please help to fix this issue.

4

@GarnikGiloyan,

It’s not the code. I’m just using Insomnia as a raw HTTP client. And I’m calling the same endpoint.

When I make an authorization request using https://api.atlassian.com/oauth2/authorize/server/consent, then I see dozens of sites where I have user access but have not granted my client permission:

image
image568Ă—743 34.8 KB

I choose 1, and “Accept”.

Then I get an authorization code and exchange it for an access token using https://auth.atlassian.com/oauth/token. With that token I call https://api.atlassian.com/oauth/token/accessible-resources. The response doesn’t have dozens of sites. It just has the set that I have granted access; in my case, I only ever grant access to 1 site:

[
	{
		"id": "c68adbe0-2b09-4add-b08e-eb5797b31bc9",
		"url": "https://devpartisan.atlassian.net",
		"name": "devpartisan",
		"scopes": [
			"write:confluence-groups",
			"write:confluence-space",
			"read:confluence-content.permission",
			"write:confluence-content",
			"read:confluence-props",
			"manage:confluence-configuration",
			"read:confluence-groups",
			"read:confluence-content.summary",
			"read:confluence-user",
			"search:confluence",
			"read:confluence-space.summary",
			"write:confluence-props",
			"read:confluence-content.all",
			"write:confluence-file"
		],
		"avatarUrl": "https://site-admin-avatar-cdn.prod.public.atl-paas.net/avatars/240/site.png"
	}
]

That said, accessible resources can return multiple sites. The client does not know which one was “the last one” for a given user, so clients will need to disambiguate some other way.

3 Likes
5

As of a few weeks ago, we are encountering these issues for the first time on our application, which has been working fine with multiple Jira instances for years. We’re not sure if it’s a code change that exposed a pre-existing issue, or if the API is behaving differently.

https://api.atlassian.com/oauth/token/accessible-resources on my OAuth 2 token is providing an array of 4 objects which have id. When I iterate over each ID and call https://api.atlassian.com/ex/jira/{ID_GOES_HERE}/rest/api/2/project/search?expand=issueTypeHierarchy&startAt=0&maxResults=100, the first 3 give me a page of results, and the 4th ones responds 403 The app is not installed on this instance.

Our work-around will probably be to catch such errors and retroactively filter it from the list of accessible resources, but that could lead to unexpected behavior. @ibuchanan please let me know how I can assist in diagnosing this issue since it appears to be a legitimate bug based on what you’ve posted in this thread.

6

@jordanw,

Indeed, if you have a bug, you may report it to Atlassian developer support. To help them diagnose the problem, it will help the support ticket get started faster if you can share your client id, and any atl-traceid headers from these requests.

1 Like
7

Hey! I’m facing the same issue. I tried your approach of making another request, like getting the project, but I ended up retrieving project details for all cloud IDs when I only needed authorisation for one. @ibuchanan Please let me know if there any way to resolve this issue.

8

In case it helps you or anyone in the future, I’ll let you know what happened in my case. After 5 months of back-and-forth with Atlassian support, we identified two issues:

  1. The accessible resources were doing some kind of union on access permissions. If the OAuth app added a requested permission and got approved by the user on a new Jira instance, it would report on the API the same expanded permissions on all accessible resources, even though the older approvals didn’t actually have the new permissions. After helping them to identify this issue, this bug was fixed by Atlassian in Q3 2024.
  2. One particular user who happened to be in our own org had an extreme edge case which our many thousands of external users didn’t encounter. As I understand it, for some reason that user had permission to use Jira on that instance, even though Jira was no longer installed on that instance… or something along those lines. Here it is straight from the rep:

After investigating this issue with multiple dev teams, we’ve finally identified where a fix can be implemented.

However, in the course of the investigation, we’ve also found out that the issue is extremely rare to occur. To be honest, event after replicating the scenario this particular user has in multiple environments/sites, the issue isn’t reproducible.

And, with Jira Software and Jira Work Management merging into Jira this is even unlikely to happen. But, our dev team will still be working on remediating the issue and you can follow the bug with this JAC.

To remediate the issue with this specific user/site pair, you can either suspend access to the site or adding “user” access to a product.

I’d recommend that you watch / vote for the above for our dev-teams priority alignment. You can also review the following document on how new features / bug fixes are implemented.

That’s in the long-term backlog, and seems unlikely to make progress any time soon. But to be honest, my org is not terribly concerned. When we suddenly started having issues one day in March, we were really worried that it would impact a lot of users, but after having the first bug fixed (which solved the issues for everyone but one person), by that point it had already been 5 months since we first saw signs of trouble, and we still weren’t getting reports for our users. So simply waiting it out proved it to be kind of a non-issue for our customers. So we simply moved on.

Not sure if that’s of any value, but I know how annoying it can be to scour the internet and wonder how it turned out for that one other user, so there it is. Best of luck.

3 Likes
9

@ibuchanan The current OAuth 2.0 flow implemented by Atlassian presents significant usability and security concerns.

According to OAuth 2.0 standards (RFC 6749), an access token should explicitly reflect the scope of access granted. RFC 6749, Section 5.1, clearly states:

The authorization server MUST include the granted scope if it differs from the scope requested by the client.

Additionally, RFC 6749 highlights that scopes are meant to define the level of access or permissions granted by the resource owner to the client, which must be clearly reflected in the access token or associated response.

Currently, Atlassian’s implementation of the accessible-resources endpoint returns all resources associated with the user rather than the specific resource explicitly authorized during the OAuth 2.0 consent process. This approach contradicts the OAuth 2.0 principle of explicit scope consent, leaving ambiguity about which specific resource the user has authorized.

To comply with OAuth 2.0 standards and best practices, Atlassian should ensure the issued access token or a related response explicitly indicates the authorized resource, such as through the inclusion of CloudId or another unique resource identifier.

I think at least through this adjustment you would remove ambiguity, and align clearly with OAuth 2.0 standards.

2 Likes