Far too short notice on webhook verification change

Format Your New Topic as Follows:

API Endpoint(s) and/or Zoom API Event(s)
Notification of webhook validation changes: https://devsupport.zoom.us/hc/en-us/articles/13348844740365-Webhook-validation-and-verification-changes

Description
That is a giant change to be making and only telling us about only one week ahead of time. Please reconsider the deployment timeline on this. The other change in that past is scheduled for August 2023, which we have time to plan for.

We have too many shared users who will be quite negatively affected by this. I urge you to postpone.

4 Likes

We have 7000 shared monthly active users who will be negatively impacted if this timeframe stands

Hi there!

We urgently need more information on this change.

The documentation on the new process says to use the webhook’s secret token as the secret/salt when creating the salt. However, we don’t currently have a secret token, which raises a number of questions and concerns.

  1. If I generate a Secret Token in our app by clicking on the Generate button next to the Secret Token field, will that one start getting sent immediately? Or do I need to submit the app for review first, thus making the timeline even tighter?

  2. Since the Secret Token will be eventually taking the place of the Verification Token, if I generate a Secret Token will it stop sending the Verification Token in every webhook? We rely on that verification token now.

Can you clarify this line:

This will be required for new webhooks created after this date.

Does that mean if we already have a webhook (event subscription) set up that nothing will change until we create a new one?

Hi @scott.halgrim, thank you for the feedback, we’ve shared with a number of teams working on this.

What you’re seeing is a new requirement in our app creation process and not an enforcement on existing subscriptions. New webhook subscriptions will require a challenge-response check, but existing subscriptions have until August 2023 to implement validation.

1 Like

I’m checking with our Product and Engineering teams on the effects of generating a secret token for a published application / subscription created before this release. My understanding is we will continue to send verification tokens for existing subscriptions but want to confirm.

Thanks, Michael. I really appreciate that. Look forward to hearing about how long existing verification tokens will be sent, but the clarity on the rest of this is :100:

1 Like

Confirming here, we will continue to send verification tokens for existing subscriptions :+1:

For chatbots that use event notifications, will the verification token continue to be sent after Aug 2023/ Oct 2023? We have some reverse proxy servers that rely to inspecting http headers to allow zoom event traffic in… (these reverse proxy servers intercept the event notifications sent to our bot and then relay it to our bot)

These devices, such as F5, are not capable of calculating HMAC hashes to allow traffic through, so they need to rely on some value they can match in a header.

Hi @gauraves ,

The verification token change is intended to affect all event notifications: Using webhooks

Hope this helps!

The configuration for chatbots for secret token and verification token is done in a different place and it is done on an individual bot level basis. (See screen shot below for example).

To clarify, we are not talking about messages sent to Event notification endpoint URL for our chat bot but our regular chat messages (user types Hi in the chatbot conversation window) that is sent to the bot end point URL. These are not called Event Notifications in the docs which can have their own end point)

For webhooks it appears that the changes need to be done globally, and for example, if one opts for the Custom header approach, will affect ALL web hooks. (Using webhooks )

Does this mean that the global configuration of web hooks will also apply to the chat message events of chatbots sent to the bot end point ?

If we use the custom header approach in web hooks will the messages sent to ALL chat bots in our tenant also get the same custom header?

Alternatively if we use Basic Auth approach to validating webhooks, will it over ride the http Authorization Header with the Basic Auth Authorization? (Recall that currently the same Authorization header is used by Zoom to send the Verification Token)

Hi @gauraves , thank you for the additional context here.

@ojus.zoom @shariq.torres , do you have any knowledge on this to help clarify?

@gauraves

1] Since the verification token will expire in october, you will have to use the secret token to verify the events for chatbot endpoints too.

2] I did some testing with the Basic Authorization for zoom webhook endpoints, here is what it means:
a. The authorization part is just for the developer to understand that the events are coming from Zoom. It will be sent to the developer when they receive events (not the one to validate the endpoint)
b. Zoom gives you a choice whether you want to verify it by the default method or use other methods that are provided
c. However you will still need to validate your endpoint with the secret tokens first before you receive the events
d. The authorizations are not available for Zoom Team Chat apps at the moment, so you will receive the default authorization in the headers for the bot notifications even if you have selected a different one for your regular webhooks.

Here is a sample code for receiving basic authorization header:

const express = require('express');
const bodyParser = require('body-parser');
const crypto = require('crypto');

const app = express();
const port = 4000; // Choose a port number that suits your needs

// Middleware to parse JSON request body
app.use(bodyParser.json());

const ZOOM_WEBHOOK_SECRET_TOKEN = ""

// Middleware for Basic Authentication
app.use((req, res, next) => {
  const authHeader = req.headers.authorization;

  if (authHeader) {
    const auth = Buffer.from(authHeader.split(' ')[1], 'base64').toString().split(':');
    const username = auth[0];
    const password = auth[1];

    // Compare the username and password with your desired credentials
    if (username === 'abc' && password === 'abc') {
      return next(); // Proceed to the next middleware or route handler
    }
  }

  // Authentication failed, send 401 Unauthorized response
  res.set('WWW-Authenticate', 'Basic realm="Authorization Required"');
  res.status(401).send('Unauthorized');
});

// Webhook endpoint
app.post('/webhook', (req, res) => {
  const webhookEvent = req.body.event;
  
  if (webhookEvent === 'endpoint.url_validation') {
    const plainToken = req.body.payload.plainToken;
    const hashedToken = crypto.createHmac('sha256', ZOOM_WEBHOOK_SECRET_TOKEN)
                            .update(plainToken)
                            .digest('hex');
    
    const responseJson = {
      plainToken: plainToken,
      encryptedToken: hashedToken
    };
    
    res.status(200).json(responseJson);
  } else {
    // Handle other webhook events here
    console.log('Received webhook:', req.body);

    // Send a response to acknowledge the webhook
    res.sendStatus(200);
  }
});

// Start the server
app.listen(port, () => {
  console.log(`Webhook endpoint listening at http://localhost:${port}`);
});

1 Like

Does this mean that the Teams Chat Apps will continue to receive the Authorization header (which currently contains the Verification token)?

When will Teams Chat Apps require to upgrade the verification mechanism?

Thanks

@gauraves to my understanding, the verification token value will be replaced by the secret token. But let me do some digging and get back to you

Any updates on this?

@gauraves , we are still working on this. For now, here is what you can expect:

a. You are not required to validate the bot endpoint URL for now, however this might change in the future and we will communicate accordingly.
b. The verification token value will be replaced by secret token value once it retires

@ojus.zoom I have a similar question for the Deauthorization Notification (Deauthorization). We are currently using the Verification Token in our endpoint to verify that the request came from Zoom, but since this method of verification is expiring in Oct. 2023, can we expect that the Deauthorization Notification will also need to use the encryption method with the Secret Token specified in Using webhooks?