Server to Server OAuth tokens and concurrent usage (e.g. web apps)

API and Webhooks
1

We have a working JWT app today which looks up guest (not users in our Zoom account) participant attendance information in meetings hosted by users in Zoom account. These API calls are invoked by those guest participants coming to a web page and requesting verification that they attended. So there can be many concurrent requests that are using our JWT token.

Great, so now we’re planning for the switch to Server-to-Server OAuth. Am I right to conclude that each call to https://zoom.us/oauth/token?grant_type=account_credentials will not only generate a new bearer token (TTL 1 hour) but also invalidate the previous bearer token? And if so, our concurrent API calls will step all over each other in race conditions obtaining new tokens but then not being able to finish their actual API work because yet another new token was obtained on behalf of another participant’s request.

I hope I’m wrong. If I’m not, how are people in similar situations migrating from JWT? Introducing a token middleman who is in charge of persisting the token, handing it out when valid, and refreshing it when expired (and making all requestors wait/retry while that refresh occurs)?

Thanks for your insights!!
Shawn

2

We check if the token has expired, and if so, start a database transaction, use SELECT ... FOR UPDATE to fetch and lock the row, check once more to see if the token has expired (in case another thread has beat us to running the update and if so we short-circuit out of the transaction), refresh the token and commit the transaction. Now any other concurrent threads will also see the refreshed token.

3

I found this: Randomly receiving “Invalid access token” for Server-to-Server OAuth - API and Webhooks - Zoom Developer Forum, for anyone else looking. But looks like basically yes, we need to introduce a token manager-type function into our backend so the rest of our app business logic doesn’t have to be concerned with it.

4

Thanks Ryan! Take a look at that other thread I found too… the token_index parameter where Zoom will let your app have multiple valid tokens. Still needs to be managed, but it would be a little cleaner.

5

Interesting… though you still need a way to serialize incrementing the token_index, which brings you back to database transactions :smiley:! But I can see some potential use cases for it…

6

Yeah…it’s a pain, but this seems to be what’s available for the moment. You’ll need to work with your Zoom account rep to get your index count increased as well…it’s not just enabled by default. This gives you a batch of valid token indexes to work with (e.g. token_index 1 through 5, for example).

Whether you want to persist these tokens in your DB or some other data store is up to you. In our particular use case, we’re running in AWS, so I’ll likely use something like SecretsManager or SSM to store the oauth token(s) rather than putting additional load on our database.

7

You people are joking, right? Just to summarize, instead of simply using a cached token that’s not expired and getting a new one otherwise (and caching it for its lifetime), I’m actually supposed to:

  • implement synchronization so parallel requests don’t end up each getting their own token (race condition → one will be invalid)
  • implement a background task that generates tokens to avoid the need for synchronization
  • create separate oauth apps for prod/staging (least problematic part, just an inconvenience)

I get it that you want to replace the super-powerful JWT tokens (which had no scopes), but allowing a decent amount of active tokens - automatically, not with an explicitly-specified “token index” is standard. Nobody besides Zoom is doing this weird token_index thing

9

This topic was automatically closed 368 days after the last reply. New replies are no longer allowed.