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

Hi @pvdh ,

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?

Thanks,

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.

Hi @MultiplayerSession ,

Thank you for your suggestion. We do have a work around at the moment. We can increase the index (by default 0) of your app. In this case (lets say your index is increased to 5), a token generated at index 0 will work independently of a token generated at index 1. They will still have an expiry of 1 hour though.

You can specify the index for the token by appending the “index” query parameter to your token request.

1 Like

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).