Enhanced Validation of OAuthClientIds

What is changing?

Connect allocates each app a unique OAuthClientId. During the installation of an app, Connect passes the OAuthClientId to the app along with other parameters in the installation payload. When a site undergoes an import operation, the site’s clientKey will change and all connect apps are removed. If the app is subsequently installed on the site, the app will receive a new install callback with the new client key and an updated OAuthClientId value.

Atlassian Connect is enhancing the security of impersonation token requests to ensure older OAuthClientId are no longer accepted.

Currently older OAuthClientIds for a site may be used to send impersonation requests. This change will ensure that any received OAuthCliendIds are current, otherwise, the call will be rejected.

Once these changes reach production, an app making a token request using an expired OAuthClientId will receive a response with a 400 status code.

Why is this changing?

This change enhances Connect security by ensuring old OAuthClientId values can not be used. We realize that many apps have retained these old values and the associated clientKey values.

When will this change take effect?

We had commenced a progressive rollout of this change as we did not expect apps to be using expired values. In addition, where apps did use old values, we did not expect failures to cause significant issues for apps. From app vendor feedback we now realize this impacted some app operations.

We plan to re-commence rollout of this change in a more progressive manner.

  • May 12: Changes will be released to the Jira and Confluence Cloud Vendor First program.
  • June 16: Changes will be progressively rolled out to all remaining Jira and Confluence tenants on an app by app basis. Over a two week period, we’ll increase the percentage of apps receiving the change nominally from 5% to 50% to 100%.

These dates and rollout percentages may change depending on whether issues are encountered by customers.

Testing your app?

Only Connect apps employing user impersonation are at risk from these changes. If this is the case for your app, then you should following procedure to ensure the app will be affected:

At any time:

  1. Create a new tenant by visiting http://go.atlassian.com/cloud-dev.
  2. Enroll the tenant in the Cloud Vendor First program:
    Jira: http://go.atlassian.com/cloud-vendor-first-jira-form
    Confluence: http://go.atlassian.com/cloud-vendor-first-confluence-form
  3. Install your app.
  4. Export the site’s data and then import it back to the same site.
  5. At this stage your app will be uninstalled and the site will have a new clientKey and OAuthClientId.
  6. Re-install your app.

After May 12 (when the changes are enabled for Cloud Vendor First tenants):

  1. Test your app’s features that utilize user impersonation.

@cmacneill thanks for sharing this.

Few questions:

  1. Will my app receive uninstall and disable callbacks during import?
  2. After reinstalling the app after import the app will receive install, but not reinstall callback, right?

Addons do not receive uninstall or disable callbacks when a site undergoes an import.

Imports do not include Connect addons, and the site’s clientKey change. It is essentially a new site with the same content and NO Connect addons.

If, after the import, the addon is added to the site again, the addon will receive a new install callback, with new clientKey and OAuthClientId.

1 Like

Hi @cmacneill, shall we install our app using the private token in order to avoid trial expiration/billing issue?
I guess the data to test in order to validate the OAuthClientIds will not be affected by the use of the private token.


@sax Yes, the OauthClientId will not be affected by use of a private token so you can proceed to install however you would normally go about testing.

Hi @cmacneill, as far as I got we need to create two separated Confluence and Jira Cloud site in order to be able to make the import/export for both product, correct?

Hi @cmacneill,

I don’t understand: “If, after the import, the addon is added to the site again, the addon will receive a new install callback, with new clientKey and OAuthClientId.”

Can you confirm that after you import a backup on Jira cloud, you basically breaks all your add-ons because clientKey changes and there is no way to match old tenant with new one?

1 Like

Restoring a backup is slightly different from importing a site. Importing is effectively creating a new site with the same content. Addon installation information is not included in an import operation.

@cmacneill -
Can you confirm if the Jira and Confluence Cloud Vendor First program instances have been updated with this change?


@adam I have just enabled for check for the vendor program. My apologies for the delay.

1 Like

Is there a way to match old and new tenants? Just to catch the information and handle it in app side somehow? So we do not have any specific webhooks or smth like that?

Does ACE automatically support this scenario (no changes should be needed for someone using it)? I think so, but want to double check.



Today I was going to check impersonation in the developer first sandbox but when I tried to run installation of our connect app (AddOn) I got the following error (which is new for me):
“The app “(PluginKey)” could not be installed as your site has not defined all of the required default groups. This affects the installation of all apps. Please see http://go.atlassian.com/nodefaultgroup for further information.”

I visited “http://go.atlassian.com/nodefaultgroup” and manually added some groups to our sandbox instance (IIRC: “users”, “jira-developers” and “jira-administrators” (or “administrators”)). Now, our instance contains the following groups:


But, unfortunately, it did not help and the error persists.

@ivan.babikov The problem here is you need to designate some of these groups as the “default” groups for product users. Please see the section " Default groups and permissions" in the http://go.atlassian.com/nodefaultgroup link.

The “Product Access” section in admin allows you to designate which groups is the default for a product. Also the groups section clearly shows which groups are considered a default group.

Thanks, after setting default groups for projects I could install Connect App.

Could this restriction be related only to our not fully configured sandbox or may occur on some production environments?

Hello, is roll out started?

Since I was a week late getting this rolled out to the Vendor First program, I felt it best to wait to June 23 to start rolling this out more generally. It will be a progressive rollout over the following week.

Just noting that we have now commenced rollout of this validation. It will be a gradual deployment to gauge impact.