Security and user-level access limitations for Server-to-Server OAuth apps

API and Webhooks Authentication
1

API Endpoint(s) and/or Zoom API Event(s)
GET /scheduler/events

GET /meetings/{meetingId}

GET /past_meetings/{meetingId}

Description
We are building an internal automation solution that uses Azure Functions to interact with the Zoom Scheduler and Meeting APIs. To enable the required API permissions, we are evaluating a Server-to-Server OAuth app.

Our primary concern is the security model of the Server-to-Server OAuth app.

Based on our understanding, when the app is authorized at the account level and granted the appropriate admin scopes, the app may be able to access meeting and scheduling information for users across our org’s Zoom account. This creates a concern from a least-privilege perspective: if the app’s client credentials were ever compromised, could an unauthorized party use those credentials to access Zoom data for users throughout our organization?

Ideally, we would like to restrict the integration to only a defined subset of users whose Scheduler and Meeting activity the Azure Function needs to process.

Could you please clarify the following?

  1. Can a Server-to-Server OAuth app be restricted to a specific group or list of users within a Zoom account, rather than having access to all users covered by the granted admin scopes?
  2. If user-level restriction is not supported, is there a recommended Zoom architecture for an internal backend integration that only needs access to a subset of users? For example, would a standard OAuth app with individual user authorization be more appropriate?
  3. Does Zoom support automatic or scheduled client-secret rotation for Server-to-Server OAuth apps? If so, what is the recommended approach for rotating the secret without interrupting the Azure Function integration?
  4. Are there any additional Zoom controls or recommended security practices for limiting the impact of a compromised Server-to-Server OAuth client credential?

Our goal is to follow the principle of least privilege while still allowing our Azure Function to perform the required Scheduler and Meeting API operations.