Server-to-Server OAuth: annoying token-invalidation

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

Getting an access token AT1 at https://zoom.us/oauth/token?grant_type=account_credentials&account_id=xxx works fine, GET https://zoom.us/v2/users?page_size=100&page_number=1 with AT1 works fine,
requesting a second access token AT2 works fine, but doing GET https://zoom.us/v2/users?page_size=100&page_number=1 using AT1 immediately fails.

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?

Best regards
Patrick

1 Like