Unable to decode JWT token: Error: Signature verification failed for input

My development environment stoppted handling the JWT authentification today. I am using the atlassian connect express framework and the built-in JWT token handling.

I did not change anything to the code. I even went back to old revisions of my project to make sure, there was not unintended change of code. Also I registered a completely new JIRA cloud instance and tried to register my add-on there, but the same error occurs.

Here is the output in my console:

Watching atlassian-connect.json for changes
Add-on server running at http://DESKTOP-<removed>:3001
Add-on self-register
Local tunnel established at https://b55f08a8.ngrok.io/
Check http://127.0.0.1:4040 for tunnel status
Registering add-on...
GET /atlassian-connect.json 200 6.471 ms - -
{} Authentication verification error (400):  Unable to decode JWT token: Error: Signature verification failed for input: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI1ZThhZjU5Yzg0ZGVjMjBiODE1YTQyMTYiLCJxc2giOiI0YTJlMWRlOGNhNzRlNmNhZmU4ODYyZDMzMmZhM2FjN2E4ZTUxZTY5MmJjNmQ3OThlYTRkZmVkYzE0OTQ4YmY0IiwiaXNzIjoiNj
kzMDk2MTQtYWJjOC0zNTlmLWI4ODgtMGRlMmJiZTZjZTRiIiwiY29udGV4dCI6e30sImV4cCI6MTU4OTkyMTg2OCwiaWF0IjoxNTg5OTIwOTY4fQ with method sha256
POST /installed 400 18.066 ms - 398
Failed to register with host https://<removed>.atlassian.net/ (200)
The app host returned HTTP response code 400 when we tried to contact it during installation. Please try again later or contact the app vendor.
{"type":"INSTALL","pingAfter":300,"status":{"done":true,"statusCode":200,"contentType":"application/vnd.atl.plugins.task.install.err+json","subCode":"connect.install.error.remote.host.bad.response.400","errorMessage":"The app host returned HTTP response code 400 when we tried to contact it during installation.
Please try again later or contact the app vendor.","source":"https://b55f08a8.ngrok.io/atlassian-connect.json","name":"https://b55f08a8.ngrok.io/atlassian-connect.json"},"links":{"self":"/rest/plugins/1.0/pending/ef18bb2e-765c-4064-b7c1-fbb5de39bb4a","alternate":"/rest/plugins/1.0/tasks/ef18bb2e-765c-4064-b7c1-
fbb5de39bb4a"},"timestamp":1589920966813,"accountId":"5e8af59c84dec20b815a4216","id":"ef18bb2e-765c-4064-b7c1-fbb5de39bb4a"}
Add-on not registered; no compatible hosts detected

Hi @SebastianK81,

You could try adding your JWT into https://jwt.io/ to decode it to see if that shows the problem. Given that you say you’ve done nothing to your app code, maybe there’s an issue with the time synchronisation between your app’s server and Jira’s server? Also, if your app is listed in Marketplace, have you installed the Marketplace version of your app in the tenant you are running your local version of your app against?

Regards,
Dugald

Hi @dmorrow,

the decoding of the JWT looks fine. The app is not in the marketplace. But yesterday we did:

  • Deployed the app on our production system
  • Manually installed the app from the production system (by passing the url to “manage apps”)
  • Uninstalled this app from the jira account (by using “uninstall” “manage apps”)
  • After that trying to install my dev app (by automatic self-registration like mentioned above) failed

But this is still strange, because I tried to:

  • Register the app to a brand new Jira account (failed)
  • changed the key of my app in the atlassian-connect.json (also failed)

Any further ideas?

Thanks @SebastianK81. Did your app start failing locally only after you installed the production version of it? Also, what do you mean by “register the app to a brand new Jira account”? Instead of account, do you mean tenant?

@dmorrow Yes, I created a new Jira tenant with not before used email address and tried to auto-register my add-on in development mode to it. The same error occured.

When you install an app for the first time in an instance, the install request will not be signed (i.e. no JWT) so any error should be different from what you have shown above. Could you let me know the Jira instances you have used?

1 Like

Dear @cmacneill,

I send you a PM with my instance domain.

Thanks for stepping in to help @cmacneill. @SebastianK81, once you work out the solution to the problem, would you mind posting an update to this thread for the benefit of others.

1 Like

@dmorrow Yes, I just send him the name in the PM. Further discussion can continue here.

Yes, the install request is not signed. It is just that all subsequent requests fail, that worked before without a problem. As a connect express developer I did not care about JWT at all, as it is completely handled by the framework.

When you say “install request is not signed”, only the first installation request is not signed. In any given tenant, an app may be installed over the top of itself or even uninstalled and re-installed. All of these subsequent installations will be signed.

@dmorrow Thank you for clarification. However which request is signed and which not, is not the problem I have with my add-on. JWT auth broke and I don’t know why, as this is handled in lower layers of the ACE framework which I did not tamper with. So thank you for looking at my instance/tenant what is going wrong.

I checked out a fresh project from https://bitbucket.org/atlassianlabs/atlassian-connect-jira-example/src/master/ and this is able to register with my jira instance without a problem. I compared the registration process and noticed following:

On the jira-example-project:

On my project:

Both projects use this database setup (from config.json):

    "store": {
      "adapter": "sequelize",
      "dialect": "sqlite",
      "storage": ":memory:"
    }

The mistake I made was to implement this route:

  // DO NOT USE THIS, BAD CODE
    app.post('/installed', addon.authenticate(), async function(req: any, res: any) {
        console.log(req.body)
        //do something own after installation, nope this is not good!
        res.sendStatus(200);
    })

This does apparently break the first authentication between Jira and the add-on. I did not notice this break, because my dev add-on was already registered with Jira and the authentication was using and entry from a sqlLite file database that was saved before the breaking change. So I did not understand why it “suddenly” broke, because the mistake was made one month back.

1 Like