As for what happens within the CA application database: when a user is bounced back from the Zoom OAuth screen (having given their consent), the CA server then requests and stores the authorization token from Zoom. These parameters are subsequently used to make Zoom API calls.
CA happily gets and stores these credentials each time the OAuth flow bounces someone back from Zoom. Storing of credentials under one account if fully independent from storing them under another.
Hi @john , so since the user is re-authorizing, here’s what you may run into:
User has reauthorized CA is making the API call with old refresh token (from first authorization). Since user has reauthorized that old refresh token is revoked or became invalid now.
Please use the new access and refresh token from 2nd authorization to make requests on behalf of both Betty’s CA accounts.
But that’s the problem: the CA user who happens to be connecting the same Zoom account has no formal connection to the other CA user who authorized it the first time.
Again, two separate CA users, connecting to the same Zoom account.
CA has no reason to know or to be able to recognize those are using the same Zoom account. Therefore CA cannot decide that when betty@bettyscoaching.com connects a Zoom account that it should use that new token for the bett@acmecoaches.com account.
As such, the token from the 2nd authorization cannot be used on behalf of both Betty’s CA accounts.
The root problem is that Zoom seems to assume that connecting a second time indicates a user’s desire to disconnect the first. That assumption is flawed, and causes problems contrary to the user’s wishes.