API V2 authentication flow highly confusing

API and Webhooks
1

My team has built an integration using the v2 REST API from our training application that allows Administrators in our application to automatically set up zoom meetings corresponding to the training they schedule.

In building this, we have found the authentication mechanism for our customers to be very confusing, to the point that I believe it will reduce adoption levels.  Issues follow:

  1. In order to generate a key and secret, we must have each customer create a developer account. These are non-technical users who will be scared-off by reading this and will not attempt the integration.

  2. In order to create the key/secret pair, you must create an “App” which indicates this pair is associated directly with a specific app.  This is not true, as the pair relates only to the user, not the app.

  3. Related to the previous point, a user can only have 1 key/secret pair, even though they name an app.  The UI implies that you can only have 1 app integrated for a given user.  In reality, the app part is irrelevant, and the keys are user specific.

I would highly recommend removing the App portion of the UI, as it serves no purpose.  Beyond that, I would request moving the key pair into the account somewhere.  There is an API key and secret pair under meeting settings which will not work with this API.  That is the natural place for a user to look for this.  If they are not a developer, they will not want to go into the developer section of the app.

2

I agree with this, we also have done an integration and it is confusing for our clients to understand the workflow of obtaining an API key  where as integrations we have done with other meeting apps are very straight forward with obtaining the account API keys right in their profile settings. 

3

If your app has nothing to with accounts and is targeted for end users, why wouldn’t you use oAuth - No reasons for end users to even know about API credentials.  check out our blog - https://developer.zoom.us/blog/announcing-platform-support-for-oauth-2-0/

More to that, we will be launching a full stack marketplace soon which is going to simplify this process end to end. More details to come …

 

Thanks

Wei @ Zoom

 

 

4

I like the oauth flow, and that’s good to see, but it doesn’t actually resolve the questions here.  If we’re not using an oauth flow (There are reasons in our workflow that we won’t be able to do it just yet) there is still this strange alternate direct flow which doesn’t make sense.

5

Got it. You might have to wait for few weeks and adapt to your marketplace framework when we launch it. That will also use oAuth and that’s our direction going forward. 

 

Regards, 

Wei @ Zoom