Refresh token workflow for multi-tenant apps

Strategies for refreshing access tokens for admin scoped apps with many users (ie 1 token to many users)??

App description

We have a multi-tenant OAuth app that leverages admin scopes to create groups and group settings. All users in the group then inherit the settings set by the admin. We then, from our app, make requests on behalf our users to get basic meeting details. The access/refresh tokens are assigned to the customer account (parent) and used by the account’s individual users (children).

Example Problem

Multiple users under the same customer account have events that occur close to each other (eg multiple meeting.started events for users at 12pm). Their access token has expired so any API requests to fetch meeting details will fail with a 401 status until we refresh the customer’s token. Since there are several users attempting to make API requests using the same token, it appears that there exists the possibility for race conditions if each of said users attempts to refresh the expired access token at the same time. Unfortunately, if one of the refresh requests fails or if we save the wrong refresh token, all subsequent requests will continue to fail until we ask our customer’s admin to disconnect and re-authorize our app with Zoom via the OAuth consent workflow.

Question

We’ve considered automating the refresh workflow in a background job/service (eg refresh all accounts’ tokens every 55 mins) to ensure that there is only one place where refresh requests can be made and persisted. Are there other strategies for handling this type of setup?

I’ve also seen answers in other topics on here that mention “increased tolerance limits”. Is that something that would apply to our setup?

You’ll want to implement your own key rotation strategy. I’ve outlined a proposed two-key rotation strategy if you have a shared database that relies on exactly one process succeeding on an UPDATE / WHERE statement matching the original renewal time, but if you anticipate long periods of inactivity, you’ll additionally need to decide what the others should do while the winner is renewing the access token — maybe reschedule your process to rerun in a minute.

I recommend creating duplicate applications for however many concurrent tokens you need, but others have had success with asking Zoom Developer Support to increase the number of tokens per application.

1 Like

@MultiplayerSession Thanks for the thoughtful response. Both solutions make sense.

Dumb follow up question: the two-key rotation strategy requires a Server-to-Server OAuth app type correct?

Our application was originally built using Zoom’s basic OAuth app type, since S2S was not available at the time.

Key rotation is a general concept that isn’t specific to any particular type of application. I first heard about it from Office 365’s DKIM signatures in DNS records, but I can’t locate the original blog discussing it anymore. The same concept applies to SSL certificate renewals, which might be more familiar.

The rough idea is you have two valid different keys that can be used, and you swap between them as the old one expires and let the usage of the old key drain out naturally. For Server-to-Server OAuth applications, you only get one key per application by default, so you’ll need to make your own second key either by creating a duplicate application or working with Zoom Support to increase your token_index quota.

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