Action Required: Breaking changes to webhook auth and validation

[Ralpharama]

Hi there, I got this email from Zoom and wondered if it was relevant for ZoomNET? https://devsupport.zoom.us/hc/en-us/articles/15916365123213

As part of our continuing efforts to improve the Zoom Developer Platform, we are making changes to how webhooks are validated and verified. Previously, we communicated to you that changes to the Zoom webhook functionality would take place in October 2023, but we are extending the deadline for this until February 3rd, 2024.

To avoid decreased app and/or integration functionality, please take the required action prior to February 3rd, 2024.

Breaking Change:

The verification method for webhooks will use the secret token value and the custom x-zm-signature header.
All webhook URLs must be validated using the new challenge-response-check mechanism.
Required Actions:

Use the new webhook validation logic to validate webhook URLs created after October 2022 and upgrade existing webhook URLs to use this process by February 3rd, 2024.
Optional Actions:

Update your app’s webhook verification logic to use either Zoom’s request headers or your own custom headers to replace the validation token by February 3rd, 2024.
You can read more about this change in the FAQ. If you have already validated your webhooks using the newer method, then there is no further action needed on your part.

Thanks!

[Jericho]

@Ralpharama Thank you for forwarding this information. ZoomNet is already capable of handling the challenge-response-check mechanism so you can prove to Zoom (when initially configuring your webhook subscription and every 72 hours thereafter) that your app is indeed running and capable of handling webhook messages. Not only that, but also ZoomNet can verify that incoming webhook messages are legit which allows you to reject the ones that seem suspicious.

By the way, I find it very confusing that Zoom uses two similar words ("validation" and "verification") to describe these two distinct features. Is it just me?

I wrote two sections in the readme to describe how these two features are handled by ZoomNet (here and here). I also wrote a code sample demonstrating what I consider to be my "ultimate" webhook handler which handles both validation and verification.

One more thing to note: not only can ZoomNet handle webhook messages that you receive via HTTP, but there's also a ZoomWebSocketClient in case you want to receive webhook messages over websocket rather than HTTP. This is briefly described here. However, it occurs to me that I didn't convert my "ultimate" handler to work with web sockets. That's an improvement I'll make to the readme shortly.

Final thought on webhook URL validation: when you configure your webhook subscription, you are given three choices regarding the authentication header:

My "ultimate" webhook handler was designed for the first option ("Default Header provided by Zoom" in screenshot above) but I suspect only the following line would need to be adjusted if you pick one of the other options.

var signature = Request.Headers[ZoomNet.WebhookParser.SIGNATURE_HEADER_NAME].SingleOrDefault();

This is something that would need to be tested. Any help would be greatly appreciated.

[Ralpharama]

Thanks for the extensive reply! I've actually deactivated our webhook app in favour of polling Zoom via the API but I may look back into using webhooks again in the future and if so I'll update you if I can help at all. Thanks once again for your great work here.

[Jericho]

it occurs to me that I didn't convert my "ultimate" handler to work with web sockets.

As far as I can tell, the concepts of "validation" and "verification" don't seem to apply to webhooks over websockets. Therefore, there is no need to convert my ultimate handler.