Cool!
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.
Right,
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.
In our example, betty@acmecoaches.com within CA is a fully separate entity from betty@bettyscoaching.com.
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.
Ahh I see @john !
This is by design and I do not believe there are intentions to change this.
If thereās a way you can cross reference the Zoom user info from the auth instances across the CA accounts, that would be your best bet.
That is very disappointing.
In that case then Iām left to wonder: what was token tolerance originally rolled out for, even if shortly, if not for address that problem?
Hi team, we are currently in the same situation.
Do you plan to get back to increasing token tolerance?
Hi @ktraczyk , last I checked, the answer was no, but Iām happy to advocate on your behalf to product. In your own words, can you please describe the roadblock youāre facing with current token status?
Hi @gianni.zoom
Users in our app can have multiple workspaces. In each workspace we threat user as a separate entity which means that whenever user switch workspace and connects Zoom previous token gets revoked.
It is really inconvenient for the users as they are getting disconnected from Zoom frequently.
Thanks for sharing @ktraczyk , Iāll see to pass this info to product.
Hi @gianni.zoom , do you have any updates regarding this issue?
Hi @ktraczyk , it does not seem like thereās capacity to reconsider re-instating token tolerance increases at this time.