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:
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.
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?
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?
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.
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?
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 Create and update groups | Atlassian Support for further information.”
I visited “Create and update groups | Atlassian Support” 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:
@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 Create and update groups | Atlassian Support 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.
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.
Today I turned into going to test impersonation inside the developer first sandbox however after I attempted to run installation of our connect app I were given the following blunders (that’s new for me). The app could not be hooked up as your web page has now not defined all the required default website. This affects the installation of all apps
