Reading through the 3LO authentication here: https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/, I was confused a bit about if it’s possible to get the cloudid of my application if I distribute it to multiple users. From the documentation, it seems that requests to https://api.atlassian.com/oauth/token/accessible-resources will always return a list of every single resource my app has access to. If that’s true, how do I differentiate the user I’m currently taking through the auth process with my app? Do I just have to manage the current list of installation ids, and then find the newly added id by seeing which one isn’t in that list?
Any help would be greatly appreciated!
2 Likes
Welcome to the Atlassian developer community @DanielSoffiantini
To clarify, the authorization code flow is granting your app access to an intersection of 2 security contexts:
- a user, who is being prompted to authorize your app
- a site, that the user must choose during authorization of your app
A site is “an instance” of Jira. Sometimes the term is known in broader SaaS terms as “a tenant”.
If you want to retrieve the public profile of the current user (for which you have a token), then you should make sure your app requests the read:me scope, and request GET https://api.atlassian.com/me. This tells you “who” your app knows, but not “where”.
Now to know which Jira sites and associated cloud IDs the token will allow your app to access, then you need to ask https://api.atlassian.com/oauth/token/accessible-resources. For that endpoint, the idea of “resources” are not the users (each authorized token only grants your app access to 1 user), they are the sites because each user may be part of many sites.
2 Likes
Thank you so much for your reply @ibuchanan, this makes a lot of sense. So what your response also implies is that access tokens returned by the call to https://auth.atlassian.com/oauth/token with the code from the auth flow are scoped to the user and not the app. Is that correct?
Also, just to be extra clear, the steps to get the user/installations combo would be:
- Send user to auth url
- Grab the code from the callback and reach out to
https://auth.atlassian.com/oauth/token
- Take the JWT response and call
https://api.atlassian.com/me and grab the account_id
- Call to
https://api.atlassian.com/oauth/token/accessible-resources and check what installations I can access with that token
1 Like
Yes. And I confirm your steps make sense when Jira and/or Confluence scopes are being requested.
Small caveat for the sake of good error handling, there are circumstances when accessible-resources can return an empty array []. This happens when your client asks for scopes that aren’t associated to a site. As specific example, read:me is not site-specific. This can be confusing because the end-user authorization flow doesn’t change: it makes the user select a specific site as if it were authorizing to that site.
1 Like
@ibuchanan could you provide some details about the case where accessible-resources returns an empty array ? I have this kind of problem, and the only hint I could find on the internet was your message above.
My use case is the following :
- I create an Oauth2.0 application
- I connect to this app with my user for a given site, and do some stuff with Jira Cloud API
- I revoke all the access to the site for my user (ie. remove it from all groups)
- I restore the access to the site for my user (ie. add it back in the groups)
- I try to connect to my app => I get an empty array for
accessible-resources
Once I reach this state I am unable to list accessible resources for my user, and I have to create a new application to have access the site with this user through the API again.
@apidevauditool,
If you were performing these steps through the UI, I think this would be exactly the expected behavior. In other words, if you remove a user’s access to the site, then that user shouldn’t be able login anymore.
What confuses me is step 4. I’m not sure how that is possible. Are you sure you aren’t getting errors? I don’t think the problem is with your client id and secret, but that the authorization provided to the client is no longer valid. Hence, no accessible resources. At this point, I’m not sure if even re-authorization should work since step 3 has removed them from the site (and I’m not entirely convinced step 4 is successful, even if the API says 200 OK).
@ibuchanan sorry it seems like I did not provide enough details.
I have 2 accounts :
- a developper account (A), that creates an OAuth2.0 application (my-app), and is administrator for the site my-dev-site
- a user account (B), that has access to the site my-dev-site, and is part of the group jira-software-users-my-dev-site
Using the UI, I can confirm that account B has access to my-dev-site, can list projects, and so on.
Now if I connect to my-app with account B, I can access my-dev-site through the jira cloud API and use it to list tasks for example. Fine.
Then, here is what I do:
- From the UI, with account A, I remove user B from the group jira-software-users-my-dev-site => user B is not part of any group on my-dev-site
- From the UI, with account A, I add user B in the group jira-software-users-my-dev-site => user B is now back in the same state as step 1.
- From the UI, with account B, I access my-dev-site => everything works fine, I can see projects and tasks
- I try to connect to my app with account B => I get an empty array for
accessible-resources, and I can never get the accessible-ressources to work again for this app and this user.
@apidevauditool,
That’s a bit more elaborate than I have time to reproduce and track down. If you need a timely answer, perhaps you would be better off asking through DEVHELP.
@ibuchanan
Thanks for your support, I raised an issue : Jira Service Management