I’m new to the land of Zoom API and I’m confused with JWT vs OAuth for an API.
Question #1: Am I understanding it correctly that you can only have one JWT public/private/token per Zoom customer site (company A, lets say)? …and this JWT’s public/secret key information is shared across all APIs and any JWT app has access to ALL JWT API apps on the site? This seems dangerous to me in that any of these JWT users could potentially re-generate keys? Please comfort me with insightful wisdom here.
Question #2: OAuth seems a bit more secure than JWT in that an OAuth app gets its own dedicated public/private keys? And if OAuth uses ‘scopes’, does this limit the use of OAuth where JWT has more access beyond available OAuth scopes?
Question #3: With Zoom API builds, I’m sensing that OAuth is the most secure approach and not use JWT. Are their limitations by restricting to OAuth? Are their API build scenarios that ABSOLUTELY requires the use of JWT?
Waiting with great anticipation to obtain wisdom from you awesome developer humanoids.
Thank you for reaching out to the Zoom Developer Forum.
Question #1: Am I understanding it correctly that you can only have one JWT public/private/token per Zoom customer site
You’re correct in that an account can only have one JWT token. This token can only be accessed by a user that has Developer and Marketplace roles assigned. This will make sure that only authorized users have access to the JWT token. That same level of restriction exists for account-level OAuth apps as well.
Question #2: OAuth seems a bit more secure than JWT in that an OAuth app gets its own dedicated public/private keys?
JWT is an account-wide app and is available to all the admins and owners of the account. You can have only 1 JWT marketplace app registered in your account. You can generate multiple JWT tokens using the JWT keys, and the tokens operate independently of each other until expired or the credentials have been changed.
Question #3: With Zoom API builds, I’m sensing that OAuth is the most secure approach and not use JWT.
A JWT token will contain all the permissions, and there is no way to restrict it. A JWT token is only valid for your account. There isn’t an API that requires the use of a JWT token but there are APIs, such as the account-level chat APIs, that require an account-level OAuth app. You can use an OAuth App if you want to have limited permissions for your token.
In short, JWT tokens are best for server-server communication whereas OAuth apps are best when you want to make requests on a user’s behalf or if you want to limit what your app can do by scope.
On point 2, our organisation has a few internal meeting management applications that want to make use of the Zoom API to create Zoom meetings on our account.
As the JWT tokens operate independently, is it considered acceptable to have a number of internal enterprise event generating applications all sharing the same single Zoom JWT API key and API secret to generate tokens to use against the API?
So if we go the JWT approach (it’s all server to server not OAuth) can we share the Key and Secret with each of the internal applications?. This way they can all use their own local JWT.io library to create their own JWT token to use to connect to the ZOOM api as the same Zoom app?
Would this cause any concurrency issues or security problems (assuming all our servers are well behaved).
Or would it be more appropriate to create new zoom accounts, new zoom apps, new JWT keys and JWT secrets for each internal application? Clearly this would be more complex for us as we would have multiple Zoom accounts to manage, and we would have to consider how our SSO integration worked too?
You can absolutely use the same JWT credentials for multiple services that you have.
Yes, you can share the credentials with internal applications. It might be better to create an internal authorization endpoint so that you don’t duplicate the code to generate a JWT and so that you only have to change the credentials at one location, if necessary.
As long as you are using the JWT token internally, there aren’t any security concerns. You won’t run into any concurrency issues either.
As you mentioned, this would likely introduce unnecessary cost and complexity. I think the best option is using JWT or an account-level OAuth app, although that would require adding logic to handle an OAuth flow that would introduce complexity as well.
