/issue-updated webhook in Cloud add-on fails with "Authentication verification error" (http 401)

A significant amount of webhook requests (but not all) from customers’ Jira to our Cloud add-on fail with HTTP 401, e.g:

Oct 18 22:40:46 automated-log-work app/web.1: Authentication verification error: 401 Authentication request has expired. Try reloading the page. 
Oct 18 22:40:46 automated-log-work app/web.1: 2017-10-18T20:40:46.291Z - info: POST /webhook/issue-updated?lic=active&user_id=emma.some&user_key=emma.some 401 2ms

Request handling does not reach our source code. As far as I can see it fails inside the Connect library.

How can this happen for requests originated by Jira itself? Shouldn’t Jira generate a valid authentication token, so the requests succeed?
One of the reasons can be a clock drift I think. The responsible code I found is pretty self-explaining:

var expiry = verifiedClaims.exp;

            // todo build in leeway?
            if (expiry && moment().utc().unix() >= expiry) {
                sendError(401, 'Authentication request has expired. Try reloading the page.');
                return;
            }

It looks like the expiration time is encoded in the token itself so nothing can be done on the add-on side.
Therefore increasing “maxTokenAge” or “jwt.validityInMinutes” won’t have effect in that case.

Did anyone struggle with a similar problem? Is there anything we can do with that?

Thanks,
Jack

Hi @jack,

I think I had the same problem before with my add-on, particularyly the "401 Authentication request has expired. Try reloading the page." because my local time is ahead of 2mins compared to my instance’s time. So i just set my laptop’s time to “automatically set”. I’m hosting the add-on in ngrok from my laptop. Hope this helps.

Cheers,
Anne

Thanks Anne.

I host my add-on on Heroku and as far as I can see the time is OK there.

When I’m watching the logs live, I can see that they are only 4 seconds behind my local/correct time, which is justified assuming the network traffic and logs processings.
The problem also affects all the dynos on Heroku which makes the hypothesis about the incorrect time on Heroku even less probable.

I wonder if the clock on customers’ Jira instances can be a problem.

Cheers,
Jack

Hi @jack,

Will post here a work around solution when we’ve confirmed our discussion in Developer Support SD.

Cheers,
Anne