Guidance for switching to oAuth2 from APIv1 when provisioning users

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. 

Hi Vinay,

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

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?

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?


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 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).