Unsure about what to use

Hello,

We have an online university which includes support for Zoom meetings using the Meeting Web SDK. Previously, with the JWT app type, our clients would enter their Zoom API Key and Zoom API Secret in our app. Our app would then allow our clients to link a Zoom user with an instructor in our app, and then the instructor was able to press a button to launch the Zoom meeting. After the instructor/host had started the meeting, students could then launch and join the same meeting. The instructor and students did not need to log in or have any other interaction with Zoom in order to use the meeting through our app.

Our app is a web application, it’s a web site. When we set up a new installation for a new client they have the option to enter their Zoom account settings to set all of this up. They don’t ever need to log in to Zoom or give us their credentials while using our app or authorize the app to use their account, or anything like that. They just needed to set up the JWT app on their Zoom account, and then paste the API key and secret into our app one time.

We use some of the REST API calls to do things like list the Zoom users on the account, get a ZAK token, and start a new instant meeting.

In the upgrade documentation, it sounded like I was being pushed towards the Server-to-server OAuth, so that’s the direction we went. After changing the JWT signature algorithm, when I’m trying to join the meeting as the host/instructor, I get a message that the signature failed validation. All of my testing and validating with jwt.io shows that my signature is valid.

I found this thread:

And under #3, the first bullet says that the app must be a Meeting SDK app type, not OAuth. So, now I’m confused.

Is our previous use case still supported by Zoom? If our clients need to go into their Zoom account and set up an app type for our site, and then enter the Zoom account settings in our site (client ID, client secret, etc), then that’s fine, that’s what we were doing previously. If they need to go through other processes to authorize things then I guess I’m just looking for some guidance on what we do from here.

We’re currently using the web SDK 2.16.0.

Thanks

@tcsteve

My comments are inline

We have an online university which includes support for Zoom meetings using the Meeting Web SDK. Previously, with the JWT app type, our clients would enter their Zoom API Key and Zoom API Secret in our app. Our app would then allow our clients to link a Zoom user with an instructor in our app, and then the instructor was able to press a button to launch the Zoom meeting. After the instructor/host had started the meeting, students could then launch and join the same meeting. The instructor and students did not need to log in or have any other interaction with Zoom in order to use the meeting through our app.

You will need a Meeting SDK App’s ClientID and Client Secret for this

Our app is a web application, it’s a web site. When we set up a new installation for a new client they have the option to enter their Zoom account settings to set all of this up. They don’t ever need to log in to Zoom or give us their credentials while using our app or authorize the app to use their account, or anything like that. They just needed to set up the JWT app on their Zoom account, and then paste the API key and secret into our app one time.

You will need a server to server OAuth app for this.

We use some of the REST API calls to do things like list the Zoom users on the account, get a ZAK token, and start a new instant meeting.

You will need a server to server OAuth app for this.

In the upgrade documentation, it sounded like I was being pushed towards the Server-to-server OAuth, so that’s the direction we went. After changing the JWT signature algorithm, when I’m trying to join the meeting as the host/instructor, I get a message that the signature failed validation. All of my testing and validating with jwt.io shows that my signature is valid.

If you are trying to authenticate your Meeting SDK Web, you will need Meeting SDK’s ClientID and ClientSecret to create the JWT Signature.

Is our previous use case still supported by Zoom? If our clients need to go into their Zoom account and set up an app type for our site, and then enter the Zoom account settings in our site (client ID, client secret, etc), then that’s fine, that’s what we were doing previously. If they need to go through other processes to authorize things then I guess I’m just looking for some guidance on what we do from here.

They can still do something similar, but I won’t recommend passing keys and secret around. They will minimally need 2 app type. Meeting SDK App Type and Server to Server OAuth App type.

OK, thank you. It sounds like we use the OAuth part on our app interface where we configure Zoom and list the instructors, and start the instant meeting, and then we need to use the Meeting SDK App Type to actually join the meeting for the host and others, is that correct?

We have the JWT generated server-side, and all of the keys and things are entered by an admin when they configure our app, so only they see that. Our app doesn’t expose the Zoom settings to people other than the admin.

@tcsteve ,

To get user Zoom account data, use Zoom REST APIs.
Zoom REST APIs allow developers to request information from the Zoom platform, including (but not limited) to user details, meeting reports, and dashboard data.

To join, and start instant meetings, use the Zoom Meeting SDK. The Meeting SDK is compatible with Zoom meetings and webinars, allowing you to start, join, and run the experience in your app or website.

Note, that the SDK JWT is required to be generated on the server side.

I hope this helps clear things up.