Issue migrating JWT to Server-to-Server OAuth

I’m getting random 401 errors using Server-To-Server OAuth when paging thru results from the report/meetings/meeting.uuid/participants endpoint.

I have a list of zoom meetings (size in the hundreds). For each meeting, I’m calling the /participants endpoint. With Server-to-Server OAuth, I get occasional 401 errors causing an incorrect list of participants. This seems to affect about half the meetings in my list, but it fluctuates with each try. Using JWT, I’m able to consistently get participants for all meetings. My source code is identical for both authentication methods. The only difference is the method to generate the bearer token in the HTTP request.

Can someone please assist? Thank you in advance!

Hi @john.cunningham ,

We don’t have 401 error code documented for that endpoint. Could you please share the details of the error and expand more upon the behavior?

There’s also this guidance if you are seeing this consistently. Make sure you are logged into your developer account when you submit.

Thanks!

Apologies, I’m getting random 404 errors with Server-To-Server OAuth, not 401. Here is an example:

Request: https://api.zoom.us/v2/report/meetings/AXcwSpw5RriOPiGS2h+UEA==/participants&next_page_token=2UvGMFbu3moA2S1KJzd5YBMruAofqbjqqW2

Response:
{StatusCode: 404, ReasonPhrase: ‘Not Found’, Version: 1.1, Content: System.Net.Http.HttpConnectionResponseContent, Headers:
{
Date: Tue, 31 Jan 2023 21:18:25 GMT
Connection: keep-alive
x-zm-trackingid: v=2.0;clid=us06;rid=WEB_39af4638967abdefc9691620f717a4d1
X-Content-Type-Options: nosniff
Cache-Control: no-store, no-transform, must-revalidate, no-cache
Pragma: no-cache
Set-Cookie: zm_aid=“”; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly
Set-Cookie: zm_haid=“”; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly
Set-Cookie: zm_tmaid=“”; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly
Set-Cookie: zm_htmaid=“”; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly
Set-Cookie: cred=A633B77486B451EAB940F264E8891773; Path=/; Secure; HttpOnly
Set-Cookie: _zm_ctaid=“”; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly
Set-Cookie: _zm_chtaid=“”; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly
Set-Cookie: _zm_ctaid=“”; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly
Set-Cookie: _zm_chtaid=“”; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
x-ratelimit-category: Heavy
x-ratelimit-limit: 60000
x-ratelimit-remaining: 57777
x-zm-zoneid: VA
CF-Cache-Status: DYNAMIC
Report-To: {“endpoints”:[{“url”:“https://a.nel.cloudflare.com/report/v3?s=mQLPK%2B1ARp1rkHylDAmXOX6SLEPrhkQ%2FPSCfcRNSwrozUfthagBifowH9N1EW%2BDaZ69YFFNnxfLDgGi75QI6085NakuWl%2BOBmKtavO6HDNK8k4tYskVO4s2hkIvZ”}],“group”:“cf-nel”,“max_age”:604800}
NEL: {“success_fraction”:0.01,“report_to”:“cf-nel”,“max_age”:604800}
Server: cloudflare
CF-RAY: 79257acf0e03e770-EWR
Content-Type: application/json; charset=UTF-8
Content-Length: 140
Expires: Thu, 01 Jan 1970 00:00:00 GMT
}}

@john.cunningham , it’s happening occasionally with no change to how you’re calling the API endpoint? How often are you calling the endpoint?

Yes, my code for these endpoints is identical, but results are inconsistent using server-to-server OAuth. I’m calling the report/meetings/meeting.uuid/participants endpoint for every meeting that takes place at my company in a given day, Daily meeting list size is in the hundreds. Each time I run my program, I get a different total number of daily meeting participants using server-to-server OAuth. Results are consistent using JWT. This process needs to run on a daily basis.

Hi @john.cunningham , can you please share your results via private message so I can further investigate? Thank you!

This is currently under escalation review. Sharing the ticket number here for other developer and Developer Advocates who may encounter someone experiencing the same behavior (ZSEE-85355).

@gianni.zoom Following this as I think this is related to the force migration from JWT to the server-to-server tokens. With server-to-server tokens both expiring after an hour and invaliding past tokens when requesting a new one this issue manifests frequently as a race condition. Two requests coming in to our service, asking for a token around the same time will invalidate the others token before it even has a chance to use it. Either let these tokens live indefinitely (not ideal) or; keep the one hour expiry but let accounts request them as needed without invalidating previous ones. Also of note, it’s not useful to have up to three “indexed” tokens here. Are we expected to coordinate between all our incoming requests who gets which indexed token? Global mutex between all our backend servers that may be trying to use these tokens?!?

For key rotation, we use a shared database that acts as a synchronization primitive to decide on a race condition winner process that renews the token for the inactive slot well in advance, then swaps that slot into active use for everyone in the same environment. This means you need 2 slots per environment, so we ended up creating multiple duplicate applications so we could have 4 slots to allocate among 2 environments.

Hi @june.lhl @MultiplayerSession ,

Appreciate your input, but the developer here is experiencing this error occasionally with a valid token nowhere near expiration while sending one request at a time.