We’re building a UserVoice <-> Jira integration via the Add-On connect framework and we were going through the process of securing the public callback APIs (configure, uninstall, and the webhook callbacks) by decoding the JWT using the shared secret and we noticed that the uninstall endpoint is called by Jira without a JWT to process. It does contain a clientKey, publicKey (this is supposedly deprecated) and the key for the Add-On.
How are we supposed to keep this uninstall endpoint secure without a JWT?
Is this a bug / gap in the Add-On workflow?
If you have responded with a success response to the initial “installed” callback, then further “enabled”, “disabled”, “uninstalled” callback should have the Authorization header with a JWT token. You should validate that “disabled” and “uninstalled” callbacks have a valid JWT authorization. Maybe in your case when you were testing it something went wrong with the initial installation of the add-on and therefore the uninstalled callback did not have a JWT authorization header.
In our case, we check that we receive the “installed” callback and then “enabled” callback and after these two events, we start to check the presence of valid JWT authorization headers. Sometimes, we do not receive the “enabled” callback after the “installed” callback which could be because something went wrong with the initial installation of our add-on in the Jira instance. When we receive the “enabled” callback we know that our add-on has been successfully installed.
If you look at the “Frameworks and tools” documentation you find links to the Connect Inspector.
The connect inspector will show you that all uninstall events for apps that have opted in to JWT authentication do include a signed token on the uninstalled event.
1 Like