Up until today we use JWT token that I could setup Bearer token once to expire at any future date.
Then we could open our webpage at anytime which on backend it curl “GET” info from our ZOOM account and show it to frontend.
Tomorrow JWT stop working, so I created Server-to-Server OAuth app and manage to get Bearer token BUT it expires in 1 hour.
How can I make it to expire in 1 year?
Redo the call to the
/oauth/token endpoint with your
account_credentials grant type to get a fresh access token.
If your application might have more than one concurrent usage of Zoom’s APIs, you probably want to implement a key rotation strategy because requesting a new access token will immediately revoke your current (previous) access token. Since you’re under time constraints, you’ll probably want to go with the multiple Server-to-Server OAuth applications implementation (instead of the
token_index increase) since that requires no interaction with Developer Support.
Thank u Christopher,
I don’t really want every time, a user opens my webpage - generate a new access Bearer token.
It is not right, because it could be, let say 5 people opening it at the same time, and token will get revoke after every single person until the last one.
Is there a way a can generate Bearer token with expiration day in 1 year and not having renew it manually/automatically every 1 hour?
With Server-to-Server OAuth, it’s no longer possible to have unlimited concurrent access tokens created on your own terms. You’re capped by (the number of Server-to-Server OAuth applications you can create, I’ve heard of people running into rate limiting at 10 applications) multiplied by (the number of
token_index values you can convince Developer Support to provision per application from an initial factory default of 1, which may be 3 as it was for me when I tried).
Thanks @MultiplayerSession At the moment we are working on supporting concurrent access tokens for server to server OAuth app. We will announce it in our changelog once we update it.
Hi Alexey !
If this helps, here’s what we did. It’s a work around. We make a call and get a new token every 200 seconds (and the other process that sets up meetings waits for the new token while this is going on). This helps us ensure that we have a valid token for as long as the job runs, and our process sets up about 2000 meetings and makes as many as 5000 calls during a 1h 30m window. Theoretically we could do this every 3500 seconds instead of 200 seconds and get away with it, but the job isn’t time sensitive so we stuck with this for now.
I am thinking the similar approach logically
- all jobs halt, get new token and store it with timestamp
- every new job coming in to make a call, checking timestamp . If < 3600 run, else go to 1.
I am gonna miss JWT old way, was no headache whatsoever