From my perspective, JTW-Auth has always been a very bad idea, since you could only have one JWT-app and no support for limiting the scope. So I really, really appreciate the new option to have account_credentials for different applications using different scopes.
However, from my perspective it is a huge issue that zoom will invalidate an active access token the moment a new token has been issued.
It is a restriction that is not even documented at Create a Server-to-Server OAuth App
From my perspective, this would be ok if there was only one single-threaded application on one server instance, but running several instances seems to be a nightmare. Synchronizing the current access token to several nodes? Getting a new AT for each request, in case a different node interfered? Hoping for the best and trying to detect interference by other nodes and hoping for the best by retrying several times? Perhaps some random delay for retries, so nodes won’t hammer the zoom-api when there is a conflict and both start retries?
Perhaps I should create an API-gateway as a proxy to place in front of the zoom api?
Is there any experience in working around this limitation?
Thank you for reviewing and providing feedback about the server to server OAuth app type. The behavior that you mentioned is an expected one. If you generate a new token, the previous token will be invalidated. This behavior is similar to our regular OAuth tokens.
We understand that yours is a rare case, and may have a workaround. Can you please create a ticket with our developersupport here and reply with your ticketID?
This topic is a concern for us as well since we have a mixture of user-initiated and background tasks that may concurrently issue API calls, and this will delay our migration from JWT to Server-to-Server OAuth. Most high availability systems allow for two concurrent valid keys to allow time to coordinate the switch from expiring keys to fresh keys.
I suppose one workaround that can be applied today is to create two identical Server-to-Server OAuth applications to simulate having two concurrent valid keys, and then key rotation between the two applications can be implemented by the caller. For planning purposes, knowing if there will be upcoming functionality changes to accommodate key rotation will help us decide whether to delay the conversion to Server-to-Server OAuth or proceed with this workaround. See the next reply for an index parameter alternative that can also be used to implement key rotation that doesn’t require creating a second application.
I’ve sent a request to Developer Support as ticket # 14947692 to allow a maximum index of 3 (allowing 2 sets for key rotation in our production and testing environments).
Update (17 August 2022): Just to set timing expectations, this request from 27 July 2022 is still awaiting approval. If your application release schedule is dependent on this functionality, you might need to explore alternatives that allow you to ship sooner. The first ticket answer I received on 5 August 2022 suggested creating multiple applications, and I had to specifically draw attention again to the index parameter offer described in this thread, so this approval might be tied to the Zoom API release schedule.
Hi all, can you please confirm that the “index” workaround is working and provide more info on placement? I tried to use it (…account_id=xxx&index=1) but the default token still gets invalidated.
The crucial tidbit of information I was missing is the correct parameter name token_index as described in:
When this token_index is out of range, you’ll receive an HTTP 400 response code with the body {"reason":"Invalid request : Maximum group number limit exceeded","error":"invalid_request"}.
Update (27 September 2022): Developer Support has explained that the number of simultaneous token index values is limited to 3 concurrent tokens due to the “higher security risk of having more index token [sic]. Our back end can’t increase it to more than 3 index token [sic] without a genuine business impacting use case, considering the security.” I’m still getting the group limit exceeded error message described earlier when trying to use any of the additional token_index values above 0, so my personal recommendation is to save yourself the trouble of working with Developer Support and just create duplicate identical applications for however many concurrent tokens you need.
I had this issue over the weekend. We have a lot of church services running on a sunday, and in the early hours sunday am I was working on our dev enviroment. I think getting a new token into the dev enviroment invalidated the active one in the live environment.
It would be really handy to see the detailed https://zoom.us/oauth/token documentation, but I can’t find it in the API reference.
I’ll create a separate app for the dev environment.
Hi @MattB
Thanks so much for reaching out to the Zoom Developer Forum and for sharing that feedback with us.
I took a moment to look into the link that you shared and you are right, this behavior is not properly documented.
I can confirm that this is the expected behavior. Generating a new token will invalidate the previous one even if the token has not expired.
I will make sure to reach out to our Docs team to have our documentation updated.
Cheers,
Elisa