Affected endpoints
POST /v2/users/:userId/meetingsDELETE /v2/meetings/:meetingId
App type
server-to-sever oauth
Description
We have a Zoom server-to-server oauth app. Our service code uses this Zoom oauth app to create and delete Zoom meetings. Here’s a typical flow:
- create_zoom_meeting()
- Check whether a non-expired Zoom access token exists in our data store.
- If so, use it for making the request to Zoom to create the meeting.
- Otherwise, obtain a new access token from Zoom and save it to the data store.
This integration worked great for about a week. Then, we suddenly started getting 401 responses from Zoom on every request to every Zoom API endpoint.
What we tried:
- The access token was not expired.
- Even if we ignored the cached access token and just requested a new token from Zoom immediately before making the request to create/delete a meeting, we still got a 401.
We were able to reliably reproduce the 401 response.
…but it started working again
Without any code changes, we started getting successful responses to these requests after making these two non-code changes:
- We transferred ownership of the Zoom oauth app to another Zoom account.
- We rotated the client secret.
Immediately after making those 2 changes, we started getting successful responses from Zoom’s APIs.
Error
401 response
Hunches
After reading other forum posts, we realized that there’s a max number of access tokens that Zoom issues before invalidating the previously issued ones that are not yet expired.
We added a fix to a race condition that could cause concurrent processes to all call Zoom to fetch a new access token, potentially exceeding that max number.
The questions
- Why would transferring ownership of the Zoom oauth app and/or rotating the client secret cause us to start getting successful responses?
- Before fixing the race condition, we might have called Zoom to fetch new access tokens too many times in a short period. Is it possible that Zoom blocked our oauth Zoom app because of this, such that we would always receive 401 responses? Note that we also tested fetching a new access token with a single process immediately before sending the API request to Zoom and still got 401, so we know that the fetched access token was valid during those tests despite getting a 401 response.
- Is there any action we might have taken with our API access that would have caused Zoom to block our oauth Zoom app and get 401 responses until we rotated the client secret? I don’t know if the app was blocked or not, but the 401 responses are suspicious.