OAuth 2.0 Changelog

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.

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.

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.

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.

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.

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.

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:

1. Updated from Auth0 (https://atlassian-account-prod.pus2.auth0.com/)

2. 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.