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

Hi @tbinna,

With regards to this scopes that aren’t available in the migration UI, we are currently in the process of fixing this.
In the meantime, a work around while we are fixing this issue is to migrate your app to the new granular scopes, selecting the scopes that are available and leave out the scopes that don’t appear in the migration UI. Then once you have migrated the app, go to the Permissions screen and edit the permissions and here you should be able to add these scopes.

Thanks,
Anna

Got it, thank you @AnnaTalebBendiab. I will give this a try.

1 Like

@JuliaDaehne are you sure about this?

I have just tested this and my app was broken once I set the new scopes live. I am sure the token refresh exchange failed right away because I have noticed the error message for that. I am not so 100% if it would also have failed if the access token was still valid.

Unfortunately, now that I have changed my dev app to the new scopes, I cannot reproduce the test anymore. As others have mentioned above this actually creates a new problem:

How can we test the migration more than once? My dev app is now migrated to the new scopes and in the UI I cannot add back the deprecated scopes. Creating a new app is not a solution, again because we cannot select the deprecated scopes.

My dev app is now locked into the new scopes and I do not see any way to perform another test to at least check if the app does also break if no token refresh is required after the migration.

5 Likes

The new scope, read:issue.transition:jira has some issues I guess.

The API ‘Get transitions’ fails with the error:

I have already provided the required scopes in the Oauth2 3LO app. (read:status:jira, read:issue.transition:jira, read:field-configuration:jira)

If you look into the list of granted scope in the above error, we can see there is api_access which replaces read:issue.transition:jira permission

Looks like there is a bug in the Jira API server which replace the required scope with ‘api_access’ is the reason for this issue

Any help will be much appreciated!

I have also noticed that offline_access is no longer listed as a scope in the documentation, neither in the supported scopes, nor in the deprecated scopes. What happened to offline_access?

Q. Will Atlassian support old scopes and new scopes for a period of time?
A. Yes, old scopes are supported throughout the deprecation period.

This seems to be false at the moment, as the deprecated scopes are no longer visible for users creating new OAuth2 Apps. This means that released code that requests the deprecated scopes are immediately broken and prevented from working with any new customers who are creating their OAuth2 Apps for the first time.

During this deprecation window, can the old scopes still be available to new Apps, albeit with a warning that they are deprecated? This is preventing new customers from using our Atlassian integrations: https://discuss.elastic.co/t/confluence-connector-non-existant-permissions/298656

1 Like

offline_access scope just mentioned in OAuth 2.0 (3LO) apps documentation and that’s only where I see.

Here:
How do I get a new access token, if my access token expires or is revoked?

Hi @RandySwift whilst we are supporting old scopes for existing apps during the deprecation period to give you time to move to new granular scopes you wouldn’t be able to create a new app with old scopes.

Hello, has anyone encountered the issue with read:issue.transition:jira scope, that it doesn’t even work?

Hi @Vishnu,

We are already looking into this, it’s probably best for you to join the conversation here about this: Adding "read🏷jira" scope (which is required to get Labels) is causing errors in other APIs - #9 by ccurti

Caterina

1 Like

Reading all this we consider to fall back to API tokens instead…

2 Likes

whilst we are supporting old scopes for existing apps during the deprecation period to give you time to move to new granular scopes you wouldn’t be able to create a new app with old scopes.

Yes this is the issue I’m reporting. Do you not see how that is a backwards incompatible and breaking change for software integrations that were previously released that request the old scopes? This prevents new customers, or existing customers creating new Apps, from being able to use established integrations. You have not given us any time here - these customers are already blocked, today.

Hi,

Once I converted our 3LO test app and applied the new scopes. I’m getting a token but using that token for any API call gets 403 error “The app is not installed on this instance”. I verified I selected this instance in the consent window

The last step for Oauth 2.0 apps is:

Update the scopes in the developer console.

Can you clarify what this is/where this is? I don’t see any place to set scopes in our app. The only place that pertains to scopes for our app is set in our app descriptor.

Hi @tbinna,

Just an update on this, this issue has now been fixed and you should be able to find these scopes in the migration UI.

Thanks,
Anna

Heya, just wanted to provide some positive feedback here - I’ve switched my OAuth2 app to the new scopes and it was pretty seamless experience. The error messages from the API listing the scopes required for each endpoint are very useful. Glad to see Atlassian taking steps to improve security.

The one comment I’d make is that since most endpoints now seem to require several scopes maybe the REST API should also be updated to be more granular to match?

7 Likes

Hi @afowler,

To update the scopes for your OAuth 2.0 (3LO) apps, go to the developer console (Log in with Atlassian account), then select the name of the app that you want to migrate, and navigate to the Permissions screen (there should be a tab called permissions in the panel on the left hand side of the screen).
Here, if the app is using deprecated scopes you should see a banner at the top of the page titled “Select new scopes for this app”. Clicking on the “Update this app” link in the banner will take you to the migration UI to migrate from deprecated to granular scopes.

Thanks,
Anna

Thank you for the update.

After switching my OAuth 2 app to the new scopes, I’ve been facing this issue I can’t make any requests using the access token, the atlassian api server response with the following error

My OAuth2 app needs both read and write scopes and I’ve noticed once I’ve added more scopes I get this error.

I’m wondering why is that and what have changed?

Update#1

It seems when I’ve removed scopes and I was able to make api requests.
Observations it seems there is correlation between number of the scopes I’ve added and whether I’m getting this error or not.

In my use case this isn’t going to work My app does need many read scopes as possible.

Even when all the scopes I needed were added, the request header size I’m sending to the api is just under 9 KB so it seems there is really issue with atlassian api server.

1 Like

Hi,
apps built for Bitbucket are not impacted by these changes, right?

Yes @PatrykKowalski, I confirm this has no impact on any Bitbucket clients.

1 Like