Guidance for switching to oAuth2 from APIv1 when provisioning users

API and Webhooks
1

Oracle is currently using APIv1 (using API key and Secret) to provision and de-provision users. 

With Zoom moving towards oAuth2, we are trying to make the transition as well, however the supported method of 3 legged oAuth2 approach is not ideal. Since this is a Service-to-Service level activity, there is no need for user authorisation to generate the intermediate access_code.

I have been requesting a transition plan for such customers who are moving from v1 to oAuth2 but was confirmed by Zoom support that there is none.

Please can I get some guidance on switching to oAuth2 for account provisioning and de-provisioning process. 

2

Hi Vinay,

We have docs on using OAuth 2 with Zoom, would these help in your case?

https://developer.zoom.us/docs/oauth/

https://devdocs.zoom.us/docs/oauth-with-zoom

3

Thanks for the links but both documents refer to the three legged approach vs the two legged approach I am after. Is there no support for 2 legged oAuth from Zoom?

4

I’m in the same boat looking for a two legged approach. I’m having a hard time believing Zoom is not addressing this. I’ve had some back and forth with support about this and all I’m getting is that I’ll need to be running a web server somewhere that I can capture the code from the redirect - which is ridiculous. Does Zoom have plans to support two legged OAuth? Is there a timeline? Are we going to end up having to code for JWT and re-code for OAuth once you decide to support this?

 

5

Hi All, 

Currently we don’t have a timeline for two legged OAuth. However, with our implementation of our Marketplace, we will have an option to continue the use server side JWT or our current OAuth flow. 

Thanks

6

Thanks for the update. Thanks for confirming that JWT will continue to be active. However support for oAuth 2 legged approach should be added on Zoom for integrations that doesn’t need human input (authorisation).

Cheers

VK