This changelog lists all the changes that may affect developers using the OAuth 2.0 platform.
The progressive rollout of data security policy events has been completed. Data security policy events are generated when installed apps' access to certain data within Confluence, Jira, Jira Service Management, or Jira Software has been blocked by an administrative policy with an App access rule. You can now subscribe to these events.
Being a new capability however, we are scaling up our processing of these data security policy events over the next few months. In the meantime we have set a upper limit of 50,000 objects. This means that if a customer activates or updates a data security policy that affects more than 50,000 objects, you will receive the first 50k objects in the events and the rest would be omitted.
We intend to raise these limits and will advise once we have reached our final threshold— and have determined our final hard limits.
Data security policies help customers keep their organization’s data secure by letting them govern how users, apps, and people outside of their organization can interact with content such as Confluence pages and Jira issues.
The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party app access to certain content in select spaces.
If you are looking to update your apps with custom in-app messaging whenever your app is affected by an app access rule, we encourage you to use the Developer guide.
Databases are currently in beta and Smart Links in the content tree are being generally rolled out as of April 2nd. In Progress
Endpoints and scopes have been added for Confluence Smart Links in the content tree and Databases. For further information about these updates, reference the Atlassian Developer Documentation for OAuth and Forge scopes as well as Confluence Cloud REST API v2.
Three new scopes have been added for each: read, write, and delete. These additions will support the implementation of Smart Links and Databases in Forge applications.
Read | Write | Delete |
|---|---|---|
|
|
|
|
|
|
Creation, retrieval, and deletion of Smart Links in the content tree and Databases have been added for v2 REST APIs. Creation, retrieval, modification, and deletion of properties as well as retrieval of operations and ancestors is supported via these added APIs.
This week we have started the progressive rollout of data security policy events generated when an app's access to certain data within Confluence, Jira Cloud, Jira Service Management, or Jira Software has been blocked by an App access rule. These events are available to subscribe to today, for App Access Rule EAP participants.
Being a new capability however, we are scaling up our processing of these events over the next few weeks. Initially only a sample of events will be sent and we will be increasing the sample progressively, aiming for 100% of events (with an upper cap) by the time the feature reaches General Availability at the end of March or early April.
Note that not all apps registering a webhook for these events will necessarily receive a sample of events, but most will.
Over the next month we will be raising these limits and will share details here once we have reached our GA threshold - and what our final hard limits are.
Starting this week, customers will be able to grant permission to Forge and 3LO Jira apps at the account level. This means that after granting permissions for their account, they no longer need to give an app permission when using the app on a new site where it has previously been installed and given permissions.
This will prevent scenarios where app functionality has been impacted in the past when the installation and app permission grant process have been out of sync. In this way, we expect this change to smooth the customer app installation experience.
Customer impacts will be limited to slightly different arrangement of the access consent screen. Also, after consenting, customers will not need to re-consent each time they use an app in a site where it is already installed.
New 3LO apps consent screen:
To read more about 3LO apps and consent, click here.
New Forge apps consent screen:
Starting this week, customers will be able to grant permission to Forge and 3LO Confluence and Compass apps at the account level, so they no longer need to give an app permission when using the app on a new site where the app has previously been installed and given permissions.
This will prevent scenarios where app functionality has been impacted when the installation and app permission grant process have been out of sync in the past. We expect this change to smooth the customer app installation experience.
Customer impacts will be limited to slightly different arrangement of the access consent screen. Also, after consenting, customers will no longer need to re-consent each time they use an app in a site where it is already installed.
New 3LO apps consent screen:
To read more about 3LO apps and consent, click here.
New Forge apps consent screen:
Next month, a small group of select customers will get early access to a new data security policy rule allowing them to limit all app access to selected Confluence spaces.
The initial EAP will work for Forge and 3LO apps only (Connect apps will be added at a later date). Partners with customers in this initial EAP will be contacted directly.
Data security policies help customers keep their organization’s data secure by letting them govern how users, apps, and people outside of their organization can interact with content such as Confluence pages and Jira issues.
The new app access rule under data security policies allows customers to restrict access for all apps to the Confluence spaces under a given policy. In this way, customers can benefit from apps while still limiting third-party access to spaces with more sensitive information.
Partners with at least one Paid via Atlassian app can check the quick reference guide for this feature in the Partner Portal for more information.
Starting today, the triggeredByUser query parameter containing the account ID of the user that triggered the webhook will be added to all webhooks. The following exceptions apply:
the account ID is unavailable,
the event is user-related,
the webhook originates from a Connect module.
On the Apr 17, 2023, the value of the issuer claim of OAuth access and refresh tokens will be:
Updated from Auth0 (https://atlassian-account-prod.pus2.auth0.com/)
Changed to the native Atlassian value (auth.atlassian.com).
Currently, this is not specified in our API documentation. For this reason, we don’t expect you to verify OAuth token issuer claims as Auth0. We're giving 3 months for the deprecation period until Apr 17, 2023.
Confluence is introducing single-space guest access to help collaborate with external teams.
Read more about the beta version of single-space guests feature on our Atlassian community post.
We fixed a bug that triggered a refresh_token is invalid message with status 400 during the OAuth 2.0 refresh grant flow. This occurred when an additional code parameter was provided that matched the format of a JSON Web Token(JWT).
Applications making refresh_token requests that matched the above condition would have seen failures (refresh_token is invalid) to exchange tokens from February 2022 onwards.
Over the next few weeks, we'll be updating the underlying OAuth2 implementation for all traffic to auth.atlassian.com. This change won’t cause any downtime during the update and shouldn't have any noticeable impact after it’s implemented. However, if you notice any issues with the OAuth flow, in particular with exchanging tokens, let us know by giving feedback.
We’ve updated the Forge CLI to reflect the changes resulting from pausing the rollout of new scopes. Forge now supports classic and granular scopes. However, if your app doesn’t have all the scopes it needs, the Forge CLI suggests the recommended classic scopes instead of granular scopes.
Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli.
On 22 February, we announced the availability of new scopes for Forge and OAuth 2.0 (3LO) apps. Following concerns raised by our developer community, we have now paused the deprecation of classic scopes and removed the requirement to transition your app to new scopes by 23 August 2022.
There is no action for you to take regarding your app scopes at this stage. Apps using either classic or new scopes can continue to do so. For those that haven’t adopted new scopes yet, please continue using classic scopes – we’ll let you know when you can start transitioning.
FAQ
Q1: I have already updated my app with new scopes. Will it stop working now?
A1: Your app will continue to work with new scopes. There is no need for you to make any further changes.
Q2: Am I going to need to roll back to the classic scopes?
A2: You do not need to roll back to classic scopes.
Q3: Does this mean the new scopes are not be reliable?
A3: Using new scopes is in no way less reliable than classic scopes. Both new and classic scopes are equally as reliable to use for your app.
Q4: Will I have to update to another, newer set of scopes?
A4: We have now started a review process of the new scopes and intend to run extensive usability studies with our partners. Once we have more clarity on the best solution, we will update you via the changelog and developer community.
An improvement will be made in the coming days to allow customers (site admins) to turn off (or back on) end-user installation capabilities for OAuth 2.0 (3LO) apps. If you are a developer of OAuth 2.0 (3LO) apps, you do not need to take any action as a result of this change, as this message is only to communicate the impact to the customer.
Previously, controls were not in place for an admin to block their users from installing 3LO apps. Adding the ability for an admin to prohibit users from installing 3LO apps now aligns more closely to how a user would install any other, non-3LO apps on the Marketplace. This functionality was requested by several Atlassian enterprise customers to gain increased control over where their data is shared and which apps have access to their instance. By allowing admins to control end-user app installs, we are making it possible for more enterprise customers to move to cloud. Once in cloud, these companies will not be blocked from installing 3LO apps, because admins will retain the ability to vet and install the apps at their discretion.
Figure (a) below demonstrates the section of the customer’s admin console where they will now be able to block their users from installing 3LO apps. Figure (b) below shows the new experience when a customer tries to install a 3LO app after their admin has disabled this function.
If a customer attempts to install a 3LO app after their admin has disabled this function, the following error message will appear:
App is blocked by an admin
An admin has not allowed [App Name] to access data from [Your Atlassian Instance] . Select another site to authorize access to or contact your admin for more information.
(a)
(b)
The original OAuth scopes for Forge and OAuth 2.0 (3LO) apps on Confluence Cloud, Jira Cloud platform, and Jira Service Management Cloud are deprecated.
All Forge and OAuth 2.0 (3LO) apps must use the new scopes by 23 August 2022 PDT / 24 August 2022 AEST. After this date, only apps using the new scopes will function as expected, as the original scopes will have been removed.
See the following documentation for more details:
Jira Cloud platform scopes for OAuth 2.0 (3LO) and Forge apps
Jira Service Management Cloud scopes for OAuth 2.0 (3LO) and Forge apps
Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli.
Rate this page: