Webhook was delayed and came with an invalid download token

[zoom-test]

Description
A meeting that was 160 minutes long and started on roughly “2020-03-16T15:00:00Z” did not have its recording completed webhook arrive until about “2020-03-19T02:32:31Z”. Nearly 2 1/2 days later. This wouldn’t be a huge problem (guessing this came late because of heavy load on Zoom) but the download_token that it came with was already expired.

Error
Download token already expired when received. This was discovered by decoding the payload and checking the expiration time.

Which App Type (OAuth / Chatbot / JWT / Webhook)?
Recording Completed Webhook

Which Endpoint/s?
Knowing the API endpoint/s can help us to identify your issue faster. Please link the ones you need help/have a question with.

How To Reproduce (If applicable)
Unsure, have an app that gets recording webhooks and record a long meeting during high traffic times

Additional context
If you want the webhook I can DM it. But it seems that sending out an already expired download_token with a webhook.is not the desired behavior.

Another question while I have you. Is the default expiration for webhook download tokens ones day? Has this changed recently?

[tommy]

Hey @zoom-test,

Please see my post here regarding the invalid download token:

Problem / AccessDenied on Downloading files from a WebHook event

Hey @tomkl, @Nicolai, We are aware of the issue and looking into if anything on the Zoom side affected this change. (ZOOM-146185) For now, the work around is to add your JWT Token to a query param to the download_url and not use the authorization bearer header: $access_token=JWT_TOKEN_HERE Thanks, Tommy

@zoom-test

Another question while I have you. Is the default expiration for webhook download tokens ones day? Has this changed recently?

This actually isn’t an issue of the download token expiring. There is a bug in code we released over the weekend, and we are working on a fix.

Also, you can stay updated about the Cloud Recording delays here: https://status.zoom.us/incidents/5hdzb14vhxyv

Thanks,
Tommy

[zoom-test]

Hi @tommy,

I’m not quite convinced that this is the same issue. This seems more tied to the delayed webhooks than downloads just not working.

That thread talks about someone who was downloading the recordings previously without adding the download_token. That is not the case for us. We add the download_token by default to all recordings we download (until downloads support OAuth token bearer authentication downloads, which was supposed to be shipped this weekend.) Those download_token’s appear to be just a form of JWT that has a hard coded expiration date/time. When we received it via webhook, it was already expired. (They can be examined using numerous tools jwt.io has one on their page).

So if webhooks were being delayed that much then that is something to look into that the token was generated, webhook sending got delayed, webhook sending finally happened, but the token was already expired because it was delayed for so long. At least that is my theory.

Also using the JWT app is not an option for us as this is marketplace app.

Again my question, what is the default expiration time for download_token’s from the webhooks? This is not documented anywhere. Right now it looks to be about a day long.

[tommy]

Hey @zoom-test,

There are a few more threads which mention the download_token was not working:

Update: Recording download url 403 error

Is this happening all over again??? Apparently getting 403 when downloading recordings in the last 18 hours or so!

Developer impacting changes during COVID-19

Has there been added authentication checks for downloading recorded lectures through download links that we get from API? Not able to download the recordings through those links after logging out from zoom.

Problem / AccessDenied on Downloading files from a WebHook event

Hey @tomkl, @Nicolai, We are aware of the issue and looking into if anything on the Zoom side affected this change. (ZOOM-146185) For now, the work around is to add your JWT Token to a query param to the download_url and not use the authorization bearer header: $access_token=JWT_TOKEN_HERE Thanks, Tommy

@zoom-test

So if webhooks were being delayed that much then that is something to look into that the token was generated, webhook sending got delayed, webhook sending finally happened, but the token was already expired because it was delayed for so long. At least that is my theory.

Good thoughts, but I’m pretty sure the token is generated once the webhook is sent.

That being said, we are working on a fix for this asap. I understand you can’t use the JWT since it is a marketplace app, I will update you once it is fixed.

@zoom-test

Again my question, what is the default expiration time for download_token’s from the webhooks? This is not documented anywhere. Right now it looks to be about a day long.

The token lasts for 24 hours.

Thanks,
Tommy

[zoom-test]

@tommy, Hey,

We saw another instance of this where the webhook from a 1 hour recording from 3/31 did not arrive till today (4/2) and the token said it expired on 4/1. Will this be fixed soon? This impacts our ability to serve customers.

[tommy]

Hey @zoom-test,

We are looking into this issue. Can you please private message me the affected meetingIDs and webhooks you received late? (ZOOM-149070)

Thanks,
Tommy

[tommy]

Hey @zoom-test,

You are right, the issue is the download_token expires before the webhook is sent.

We are currently working on a feature to fix this. I will keep this thread updated.

Thanks,
Tommy