I’m trying to create a Server-to-Server OAuth app due to the old JWT apps being discontinued. It’s mostly set up, but I’m not able to add any scopes for meetings.
The documentation says that “The administrator must add the View and Edit Users permissions to their role:”, but that’s not possible, as that would give the developer account full control over users, and create a security risk in my organization.
Since I only want the developer account to have control over meetings, and not users, what’s the proper permissions settings?
Which endpoint would you like to access? Are you aware that the JWT app type gave unrestricted access to endpoint information so if the same developer user that was handling API calls beforehand would be doing so now, they would have already had full programmatic control via API?
Looking forward to your response for further clarity!
I need to access all the endpoints around creating and editing meetings. Essentially, I need the meeting:write:admin/meeting:write and meeting:read:admin/meeting:read scopes.
I’m not sure how this relates to my issue. There’s nothing in your documentation to indicate that a JWT app was able to add/remove licenses to users in our account, but based on your own documentation, the View and Edit Users permissions do add that, and those permissions are required for access to the meeting endpoints.
Sadly, this is how that scope is assigned. As a verification, once you successfully assign that scope to an app, you can validate which role permission is needed by visiting https://marketplace.zoom.us/apphelp/<app ID> where <app ID> can be retrieved from that product’s management page URL in your Created Apps page. The table will contain the following rows:
Required App Scopes: View all user meetings
Matching Zoom Account Role Privileges: User and Permission Management - Users
View: Yes
Edit: N/A
Required App Scopes: View and manage all user meetings
Matching Zoom Account Role Privileges: User and Permission Management - Users
View: N/A
Edit: Yes
JWT app type bearer token essentially provides “God” access: access to EVERY endpoint regardless of user role. This is why I was making the point to assure you that your developer already had the ability to do these things if they were using the JWT app type bearer token
With S2S OAuth, you will need to ensure the user role AND enabled app scopes are aligned for what you are trying to accomplish.
@gianni.zoom perhaps there’s some miscommunication here. Our account admin has no issue with our app having access to all endpoints. That’s perfectly fine. The issue he takes is with granting the developer account access to user licenses.
What we’re looking for is giving our app access to those endpoints, without granting the developer account the ability to modify user licenses. How can we do that?
There’s been a recent policy change where the user that hosts the application must retain the same permissions that the applications use on an ongoing basis. We used to transfer ownership to a privileged user, have that user add the scopes, then transfer ownership back to a low-privileged user for hosting, but that is no longer viable, and if you do try to transfer ownership, ineligible scopes will be deactivated with a message.
What I’m saying is that with a JWT app bearer token, the developer account would have already had access to do this programmatically via the Users API endpoints because of the nature of the token privileges.
With Server-to-Server OAuth scope requirements, if you want your developer to access an endpoint that requires a certain scope, they will need to have the full scope privileges designated. Does that clarify things?
However, I don’t think will encourage our admin to open up those permissions to the developer account. With the JWT app, the admin was able to create it, and the developer was able to view/modify the app details, including the secrets. If the S2S app is transferred to the admin, will they able to add the scopes, and then let the developers use them?
To help the security conversations with your administrator, if a person has access to manage the app that was granted certain scopes but the hosting user doesn’t have those scopes, all the person needs to do is regenerate the access keys for the app, then use those keys to call Zoom APIs (possibly using their own code) to do anything that the app’s scopes allow. The damage has been done. That’s why this change to require the hosting user to also have the same permissions makes sense.
Consider using an OAuth app instead, and having that specific user install and authorize the application for their own use. That lets you use the non-admin scopes.
@MultiplayerSession as I stated, this is a server to server application, so no user interaction is available. This is why I asked the contact from Zoom how to do this with a S2S OAuth app.
Hi @hubinfo , to confirm, you want meeting:write:admin scope to apply to only one user on the account’s meetings? This is not possible at this time given the logic of the scope:
The suggestion from @MultiplayerSession would be your next best bet, but it sounds like it would be helpful to submit Feature Requests for expanded “Group” scopes that include meetings permissions like the above. If we were to implement something like this, you’d be able to give a developer or admin admin-permissions to certain groups and then be able to select those scopes within the Zoom Marketplace app.
In order to utilize scoped endpoints, the following conditions must be met:
The querying user must possess the necessary user permissions as required by the scope.
The application must have the appropriate scopes added to its configuration.
An access token containing the specified scopes must be generated and used when accessing the endpoints.
Adhering to these conditions ensures the proper functioning of scoped endpoints.
Thank you @gianni.zoom. It looks like the only way we’ll be able to do what we want is to separate the users between different accounts. The timeframe to have a Feature Request processed is unlikely to be less than a month.
I must say that I’m a bit disappointed in Zoom’s engineering team, as limiting scopes to the user seems like the most obvious use case.
Thanks for your feedback! Zoom Developer Platform is working diligently to iterate across all our products to help provide the best, high utility experience for our dev community needs.
