# Server-to-Server OAuth: annoying token-invalidation **URL:** \ **Category:** Authentication\ **Created:** [July 12, 2022, 11:00am UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070 "2022-07-12T11:00:01Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![pvdh](https://avatars.discourse-cdn.com/v4/letter/p/c2a13f/32.png) [@pvdh](https://devforum.zoom.us/u/pvdh)\ **Post date:** [July 12, 2022, 11:00am UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/1 "2022-07-12T11:00:01Z")
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](https://marketplace.zoom.us/docs/guides/build/server-to-server-oauth-app/) Getting an access token AT1 at [https://zoom.us/oauth/token?grant\_type=account\_credentials&account\_id=xxx](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](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](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 ---
**Author:** ![ojus.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/ojus.zoom/32/734_2.png) [@ojus.zoom](https://devforum.zoom.us/u/ojus.zoom)\ **Post date:** [July 14, 2022, 10:02pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/2 "2022-07-14T22:02:37Z")
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](https://zoom.us/zendesk/sso?return_to=https://support.zoom.us/hc/requests/new?ticket_form_id=360000996591) and reply with your ticketID? Thanks, ---
**Author:** ![MultiplayerSession](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/multiplayersession/32/66446_2.png) [@MultiplayerSession](https://devforum.zoom.us/u/MultiplayerSession)\ **Post date:** [July 19, 2022, 4:17pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/3 "2022-07-19T16:17:17Z")
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](https://docs.microsoft.com/en-us/azure/key-vault/secrets/tutorial-rotation-dual) 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](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/4) alternative that can also be used to implement key rotation that doesn’t require creating a second application. ---
**Author:** ![MultiplayerSession](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/multiplayersession/32/66446_2.png) [@MultiplayerSession](https://devforum.zoom.us/u/MultiplayerSession)\ **Post date:** [July 27, 2022, 9:17pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/5 "2022-07-27T21:17:31Z")
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. ---
**Author:** ![burstein](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/burstein/32/40550_2.png) [@burstein](https://devforum.zoom.us/u/burstein)\ **Post date:** [August 16, 2022, 6:30pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/6 "2022-08-16T18:30:45Z")
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. ---
**Author:** ![elisa.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/elisa.zoom/32/47836_2.png) [@elisa.zoom](https://devforum.zoom.us/u/elisa.zoom)\ **Post date:** [August 17, 2022, 2:10pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/7 "2022-08-17T14:10:48Z")
Hi @burstein We would have to increase the index of your app on our side. Feel free to reach out to our support team here: > **[Zoom Developer Support](https://devsupport.zoom.us/hc/en-us)** Best, Elisa ---
**Author:** ![MultiplayerSession](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/multiplayersession/32/66446_2.png) [@MultiplayerSession](https://devforum.zoom.us/u/MultiplayerSession)\ **Post date:** [September 15, 2022, 3:36pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/8 "2022-09-15T15:36:44Z")
The crucial tidbit of information I was missing is the correct parameter name `token_index` as described in: > [@Randomly receiving "Invalid access token" for Server-to-Server OAuth](https://devforum.zoom.us/t/randomly-receiving-invalid-access-token-for-server-to-server-oauth/74432/22): > > The token index is specified in the call to [https://zoom.us/oauth/token](https://zoom.us/oauth/token) by passing the `token_index` query parameter ([https://zoom.us/oauth/token?token\_index=2](https://zoom.us/oauth/token?token_index=2)) 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. ---
**Author:** ![elisa.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/elisa.zoom/32/47836_2.png) [@elisa.zoom](https://devforum.zoom.us/u/elisa.zoom)\ **Post date:** [September 17, 2022, 12:18am UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/9 "2022-09-17T00:18:24Z")
Thanks for sharing this with the community @MultiplayerSession ---
**Author:** ![MattB](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@MattB](https://devforum.zoom.us/u/MattB)\ **Post date:** [February 20, 2023, 6:09am UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/10 "2023-02-20T06:09:10Z")
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. Poor show Zoom - there’s no documentation of this, it should be clearly articulated here [https://marketplace.zoom.us/docs/guides/build/server-to-server-oauth-app/](https://marketplace.zoom.us/docs/guides/build/server-to-server-oauth-app/) Please fix and provide details of how to deal with this issue. ---
**Author:** ![elisa.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/elisa.zoom/32/47836_2.png) [@elisa.zoom](https://devforum.zoom.us/u/elisa.zoom)\ **Post date:** [February 21, 2023, 4:57pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/11 "2023-02-21T16:57:18Z")
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 ---
**Author:** ![MikeR7](https://avatars.discourse-cdn.com/v4/letter/m/e95f7d/32.png) [@MikeR7](https://devforum.zoom.us/u/MikeR7)\ **Post date:** [April 5, 2023, 6:54pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/12 "2023-04-05T18:54:00Z")
Hi Elisa, I am working on a feature within my company and am running into this same issue - previously issued OAuth tokens are being invalidated as other tokens are issued for the same credential set. Is there any known workaround or fix for this yet? As it stands right now, we will have to use JWT authentication and cannot use OAuth. Thanks! ---
**Author:** ![MultiplayerSession](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/multiplayersession/32/66446_2.png) [@MultiplayerSession](https://devforum.zoom.us/u/MultiplayerSession)\ **Post date:** [April 5, 2023, 10:38pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/13 "2023-04-05T22:38:26Z")
You’ll want to design a [key rotation](https://devforum.zoom.us/t/refresh-token-workflow-for-multi-tenant-apps/79405/2) system — 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](https://devforum.zoom.us/t/randomly-receiving-invalid-access-token-for-server-to-server-oauth/74432/15), then swaps that slot into active use for everyone in the same environment. You’ll need to create duplicate applications (each application counts as one slot) or contact Developer Support to increase your token index limit. ---
**Author:** ![elisa.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/elisa.zoom/32/47836_2.png) [@elisa.zoom](https://devforum.zoom.us/u/elisa.zoom)\ **Post date:** [April 7, 2023, 7:21pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/14 "2023-04-07T19:21:10Z")
Hi @MultiplayerSession thanks for chiming in! And @MikeR7 the insight that Chris provided is correct 🙂 ---
**Author:** ![arjun.bsci](https://avatars.discourse-cdn.com/v4/letter/a/a4c791/32.png) [@arjun.bsci](https://devforum.zoom.us/u/arjun.bsci)\ **Post date:** [April 18, 2023, 3:47pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/15 "2023-04-18T15:47:44Z")
Hello @elisa.zoom , We submitted a similar ticket [#17052166] to enable/increase the token\_index feature on our ServertoServer Oauth App. Could you please help us get a timely response & action on this ticket? ---
**Author:** ![michael.williams1](https://avatars.discourse-cdn.com/v4/letter/m/f9ae1b/32.png) [@michael.williams1](https://devforum.zoom.us/u/michael.williams1)\ **Post date:** [May 17, 2023, 6:49am UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/16 "2023-05-17T06:49:18Z")
Hi, I have submitted a similar request, #17239044, I need also the ability to use the token\_index parameter. Please help me with this. Currently I cannot use Server to Server OAuth. Thank you. ---
**Author:** ![elisa.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/elisa.zoom/32/47836_2.png) [@elisa.zoom](https://devforum.zoom.us/u/elisa.zoom)\ **Post date:** [May 19, 2023, 12:27pm UTC](https://devforum.zoom.us/t/server-to-server-oauth-annoying-token-invalidation/72070/17 "2023-05-19T12:27:26Z")
Hi @michael.williams1 Thanks for reaching out to us and welcome to our community! I was able to track down the ticket number that you shared and it looks like support has replied to you and is waiting for a follow up Cheers, Elisa