Hello, I am trying to get the API to work with the Server to Server oAuth app. I got the API to work on postman with the credentials. I was just wondering since JWT is being deprecated is there a way to get the Access Token that we need to call in order to use the API to last longer than one hour? Just wondering because if we are trying to implement this live, there really isn’t a way for us to store the access token for an hour and most likely will be used longer than an hour (random times throughout the day)
Is the only solution storing that access token? Or would it be better to just get a new access token each time the API is being called?
Hi @zoomTPMG
Thanks for reaching out to the Zoom Developer Forum and welcome to our community!
This is an excellent question!
So, as you might be aware, the access tokens generated with the Server to Server OAuth app type, have an expiration time of 1 hour so I would suggest you request a new access token each time an endpoint is called.
There is no limit on the number of tokens that you can generate per day nor on the number of applications that you can have in your Marketplace dashboard.
@elisa.zoom Sorry to bring this thread back. As far as our team can tell, requesting a new server-to-server token invalidates the previous token. When we get multiple requests concurrently that need to operate with our server-to-server token, a race condition occurs. First request gets token, uses it once. Second request comes in after first request has used token once and requests a new token. First request tries to use the token it already got, can’t because it’s now invalid. Second request goes on successfully as long as no other request has asked for a new token.
This is a pretty poor implementation of the OAuth 2.0 server tokens. They should not be invalidated by other requests for tokens, it’s why they should expire after a fixed amount of time. Having both the 1 hour expiry AND this token invalidation adds considerable complexity and noise to the whole process. Either we cache these tokens and reissue periodically ourselves (risking intermittent invalid token situations without some sort of global lock), or we force ALL requests we make to zoom to be serial in nature… greatly reducing throughput for any processing we do. How did your implementation/integration teams see these server-to-server tokens getting used as a replacement for JWT tokens (which are now sun setting).
Hi @june.lhl
Thank you so much for your feedback and for reaching out to us.
I totally understand how this issue can have a negative impact on your application.
The expected behavior for token generation with our Server to Server OAuth app is that every time you request a new access token, the previous one will get invalidated.
One of the reasons why is to enhance security in your applications and also because there is no Rate limit for you to call the Oauth endpoint.
We can offer to increase the token_index for your server to server oauth app in case you want to have multiple tokens working at the same time; with this increase, you will be able to generate tokens at different indexes and temporarily store them and the generation of a new token at a different index won’t invalidate any other token at a different index.
If you are interested in this, please reach out to our support team and request an increase in your token index tolerance here:
Hi @elisa.zoom
I am on the BASIC plan. Validating a Site-to-Site OAuth app for migration from JWT. There is a problem of concurrency, and I want to relax the number of tokens issued from the current 1 to 2. This is for the purpose of confirming that the app under test works correctly. Since contacting support is not possible for the BASIC plan, is the number of tokens limited to 1?
@MultiplayerSession Thanks!
When I tested it with Curl, throwing a request with token_index=1 resulted in {"reason":"Invalid Grant","error":"invalid_request"}, which caused confusion. I removed the token_index parameter and confirmed that the API was called with multiple tokens issued.