Rate this page:
This changelog lists all the changes that may affect developers using the OAuth 2.0 platform.
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.
We’ve added documentation about:
detection of any rotating refresh tokens being reused
the absolute lifetime, inactivity lifetime, and leeway of rotating refresh tokens
implications of migrating to rotating refresh tokens and rolling back to persistent refresh tokens
possible causes of and debugging the 403 Forbidden (invalid_grant) error
We previously announced the deprecation date of persistent refresh tokens as 30 November 2021.
We’ve updated this deprecation date to be 31 January 2022 instead.
We’ve updated the leeway or reuse detection interval of rotating refresh tokens, from three seconds to 10 minutes.
From 4th August 2021, persistent refresh tokens are deprecated. All new OAuth 2.0 integrations use rotating refresh tokens.
During the deprecation window, you’ll be able to switch between both refresh token behaviors in the developer console.
From 31st January 2022, all OAuth 2.0 integrations must use rotating refresh tokens and the refresh token options in the developer console are removed.
Learn more about this change and chat with us on the developer community post.
The Atlassian OAuth 2.0 authorization service that is currently available at auth.atlassian.io is moving to a different URL, oauth-2-authorization-server.services.atlassian.com. Atlassian is consolidating all of our public services under this naming scheme. The old URL will be retired as of January 1, 2021. See the OAuth 2.0 endpoint deprecation notice for more information.