This changelog lists all the changes that may affect developers using the OAuth 2.0 platform.
We will not be issuing any new waivers for apps that need to request or store Atlassian user API tokens. This decision is part of our ongoing commitment to enhancing security and protecting customer trust.
Forge Apps that have already been granted waivers must ensure a lack of alternative solutions within Forge. They can continue to operate, but no additional waivers will be granted for new modules or new functionality within the same app.
Connect apps that have been granted waivers and any existing Connect app requesting or storing Atlassian user API tokens are required to migrate to Forge, with tokens stored in Forge encrypted storage.
For more details, read our FAQ
UPDATE, 02 Mar, 2025 The scheduled upgrade was successfully performed on March 02, 2025 between 12:30 AM to 03:30 AM UTC, and we have verified that all the capabilities mentioned below are working as expected. If you are experiencing ongoing issues with these capabilities please contact your local Atlassian site administrator. If you need further help, please raise a support ticket at https://support.atlassian.com/#contact.
EDIT, 28 Feb, 2025 : Please note that below mentioned times are UTC i.e. 02 Mar, 2025 between 12:30 am to 03:30 AM UTC
Forge platform will be undergoing maintenance on March 02, 2025 between 00:30 AM to 03:30 AM. During this interval, below capabilities will not be available intermittently:
Create/update/delete apps
Deploy apps
Install/uninstall/upgrade apps
View existing installations
App invocations will continue to work for existing users of the apps. However, new customers might not be able to use apps as consent process will be impacted during this interval as well.
App activity logs are coming to Atlassian audit logs at the end of Feb 2025 for all admins with Atlassian Guard Premium or Cloud Enterprise licenses.
App activity logs record activity by third-party apps in the form of API calls to Jira and Confluence.
We will show app API calls for Connect, Forge and 3LO apps and related response code as well as information about whether the call was made asApp or asUser.
Admins will be able to search and filter for the app API logs through the audit log UI. To do so, they can use the ‘search’ bar or ‘activities’ filter.
Alternatively, admins can choose to register for a webhook to stream the API logs to their preferred destination for further analysis or integrate with a threat detection tool they may use.
Finally, there is also the option to use the audit log API to receive app activity logs
Rollout: Folders are currently in beta as of September 18 and will gradually go live for all customers in the coming weeks! In Progress
Endpoints and scopes have been added for Confluence Folders. 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 Folders: read, write, and delete. These additions will support the implementation of Folders in Forge applications.
Read | Write | Delete |
|---|---|---|
|
|
|
Creation, retrieval, and deletion of Folders 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.
The upper limit of for Data security policy events has been increased to 200,000 objects, from the previous limit of 50,000 objects.
How does the upper limit work
This means that if a customer activates or updates a data security policy that affects more than 200,000 objects, you will receive the first 200k objects in the events and the rest would be omitted.
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.
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. App developers can subscribe to these events, we encourage you to read the Developer guide.
CQL searches now support filtering by “smartlink” in addition to “embed“ to avoid confusion over the type for Smart Link in the content tree. Specifying “smartlink” as the type will retrieve the same results as when “embed“ equals type.
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.
Rate this page: