Confusion Between Signature Generation Methods in Zoom SDK - NodeJS

API and Webhooks Authentication
,
1

Hi everyone,

I’m a little bit puzzled with generating the SDK signature on the backend for Zoom meetings.

According to the official documentation, we’re supposed to use a method named “ZoomMtg.generateSDKSignature” (frontend side) . The steps it goes through look like this:

javascript

import * as base64JS from 'js-base64';
import * as hmacSha256 from 'crypto-js/hmac-sha256';
import * as encBase64 from 'crypto-js/enc-base64';

function generateSignature(data) {
    let signature = '';
    // Prevent time sync issue between client signature generation and zoom
    const ts = new Date().getTime() - 30000;
    try {
        const msg = base64JS.Base64.encode(data.apiKey + data.meetingNumber + ts + data.role);
        const hash = hmacSha256.default(msg, data.apiSecret);
        signature = base64JS.Base64.encodeURI(`${data.apiKey}.${data.meetingNumber}.${ts}.${data.role}.${encBase64.stringify(hash)}`);
    } catch (e) {
         console.log('error')
    }
    return signature;
}

This returns a valid Base64 encoded signature, but strangely, it’s not being accepted.

On the other hand, I found a different method on the frontend, which works just fine. It gives me a JWT encoded string, which Zoom is totally happy with. But this doesn’t match what I get when I try to recreate the function from the docs.

Instead, it’s something like this:

(Code I made) javascript

const iat = Math.round(new Date().getTime() / 1000) - 30;
const exp = iat + 60 * 60 * 2;

const oHeader = { alg: "HS256", typ: "JWT" };
console.log(req.body.meetingNumber);

const oPayload = {
  sdkKey: clientID,
  mn: req.body.meetingNumber,
  role: req.body.role,
  iat: iat,
  exp: exp,
  appKey: clientID,
  tokenExp: iat + 60 * 60 * 2,
};

const sHeader = JSON.stringify(oHeader);
const sPayload = JSON.stringify(oPayload);
const signature = KJUR.jws.JWS.sign("HS256", sHeader, sPayload, clientSecret);

res.json({
  signature: signature,
});

It appears that the two methods return vastly different results, as if the documentation has been updated but not the rest of the implementation. I’ve also been informed that JWT will no longer be usable from July onwards. However, it’s currently the only way I’m able to get a valid signature, even though the documentation suggests otherwise.

Anyone able to help clear up this fog? Is there some fresh new method of getting a valid signature that’s not in the current docs?

Thanks a million for any help you can provide!

And hey, I hope my question makes sense (and is in acceptable English). Eagerly waiting for your insights!

Thanks,
Luca

2

@luca.munari

  1. Could you share the URL where you are seeing the documentation regarding generating JWT Token with base64 encoding? I believe this is a legacy way of generating a token, and has not been accepted for quite a while now. We would appreciate if you could share the URL so we can update this.

  2. This is the correct way of generating a JWT Token.

If you are using Meeting SDK, JWT Token is the correct way to authenticate the SDK. It is not going to be deprecated.

The deprecation which is happening in Sep 2023 is JWT App Type deprecation, JWT App Type is used to access Zoom REST API, and not Meeting SDK. This deprecation does not affect Meeting SDK.

Please tag me in your reply

3

@chunsiong.zoom

Thank you so much for your clear response. It has definitely cleared up quite a few things for me.

To answer your first question, I regret to say that I’ve been unable to locate the exact source from where I found the fragment of code involving base64 encoding. I’ve been sifting through my history, but I just can’t put my finger on it. I thuink that it was likely mentioned in a thread on this forum and pointed to a GitHub repository.

Thanks again for your guidance!

Best regards,
Luca