Hello, we have a public app with a current token tolerance of 1 (any time a user can have only one valid access token) but we are using the same app in two different systems and both of these systems have integrations with active users. Now, the issue is that there might be users using both the systems and with both systems, they might want to integrate with Zoom but here’s what will happen if they do. Assume, the below case:
User XYZ logs into our legacy system and authenticate with Zoom, this will generate an access token.
The same user now logs into our newer system and integrate with zoom on it as well. This will generate another access token.
After generating the second access token, the first one gets invalidate and in the legacy integration will stop working.
I believe the answer to my problem is that I get Zoom to increase the token tolerance for my s2s-oauth app. I have the following questions now:
What is the exact procedure of increasing the token tolerance and whom should I be contacting?
How long it usually takes to get this done, i.e. get my tolerance increased.
This is the most important bit, our legacy system is using the token endpoint “https://api.zoom.us/oauth/token” and we are not using the “token_index” query parameter in that endpoint and we want it to remain like that. We do not want to make any changes in that endpoint and add the token_index query parameter to it.
Now keeping in mind point 3 above, if we increase the token tolerance of our app, will the endpoint mentioned above keep working without the token_index query parameter or after the increase in tolerance, the query paramter becomes required and we must then add the query paramter in all of our endpoints (token endpoints)? If the parameter is not required then what does that mean? Which index will be used if I do not mention the index? Will it by default mean that the 0th token index is being used if I do not specify? The reason we ask this is that we do not want to make changes to the legacy endpoint and after getting the tolerance increase, we are assuming that without sending the query parameter, it will always default to 0th index. Is that assumption correct?
Please do gives us clarity on the above, thank you.
Token tolerance for user-level OAuth apps will not require token_index, nor a difference in API querying on your end – that’s specific to Server to Server OAuth.
I will message you for your app name, developer email, production client id and token increase number and will get that processed for you
@gianni.zoom So, I do not have to use any query parameters in order to generate multiple access tokens without invalidating the previously generated access tokens? Can you share an example of how multiple access tokens can be generated for the user-level OAuth app?
We increase the tolerance for your app on our end so that you can have multiple concurrent valid tokens up to a certain number. You will not have to change anything on your end. There’s also a feature request to support multiple access tokens per app so developers can avoid this going forward (ZOOM-429593). When it is released for production, Zoom will share!
@gianni.zoom so I am getting this right, let me know if the below is correct given that I do not have to change anything at my end or mention the index number in the token calls:
You will have my app’s tolerance increased to a certain number. Let’s say 3
My users will log in using my app. If they log into three different environments using the same OAuth app, they can have three valid concurrent access tokens.
If now, they log in again, the oldest access token will get invalidated?
And also, can you please confirm whether this can be tested on an unverified app? I want to test this on our test app which has not been published on the Zoom marketplace as of yet. I want to test these changes there before I make changes into my actual production app
@gianni.zoom any updates on this? I would like to proceed with this as I would like to test this and have the app up and running. What are the next steps here and can you also respond to the above comment?
Here’s how it works:
Token tolerance [user authorized app] :
By default the token tolerance for all tokens is 0. That means if I generate a new access token with a refresh token, the previous values (access token and refresh token) will become invalid. If I increase the token tolerance, to say 5, my refresh token can be used until 5 new access tokens are generated. However the value of my access tokens will expire as soon as a new one is generated. This is helpful incase a developer looses a refresh token, the end user does not need to authorize.
Does this clarify? If you want to increase your token tolerance, I will reach out to you and get your app name, developer email, production client id and token increase number.
The notion of an increased token tolerance sounds like just the solution for a routine problem encountered by many users of our app who have multiple accounts (within our app) and wish to connect their (one) Zoom account to each.
I would very much like to increase our token tolerance, how might I do so?
@gianni.zoom Ah, that’s unfortunate, and what a quick change in support from last October!
In that case, how am I to deal with users who have multiple, separate accounts within my app who wish to connect their single Zoom account to each? This article from our Knowledge Base is what we currently turn people to when they report this issue:
I am hoping to do better, and to stop getting further complaints about this.
It’s a common and quite valid use case, and it is generally experienced as buggy behavior that authorizing a Zoom connection from one context should automatically invalidate a previous, still active authorization from another context.
How do I have Zoom not act so contrary to the wishes and expectations of the user in this regard?
Good question, and it turns out that the structuring of Zoom users under Zoom accounts is not relevant to this problem.
Here’s a scenario that illustrates:
Coach Betty has a Zoom account. Maybe she owns the account, or she’s a user under someone else’s; it doesn’t matter either way.
Betty is a coach for Acme Coaching Company, who uses CoachAccountable (CA).
Betty wants CA to be able to make Zoom meetings for the appointments she schedules via CA, so she does the OAuth flow to grant CA the ability to do so.
Betty is still working for Acme, but she also wants to use CA for her private practice. So she gets a fully separate CA account for that separate business.
Betty wants CA to be able to create Zoom meetings for her private business appointments (just like it nicely does her for Acme appointments), so she does the OAuth flow to again grant CA the ability to do so. Same Zoom account, because she has no need to keep or pay for two of them; the one serves all of her needs.
And now here’s what makes a problem that reads as buggy:
Betty is now told that CA can no longer create Zoom meetings for her appointments with Acme, for Zoom has suddenly deemed those earlier granted credentials invalid, and with no revocation on her part.
If Betty is re-authorizing the app (under the same user credentials), it will revoke the previous authorization and access token. It is not clear how Betty is segmenting private business appointment scheduling from Acme Coaching Company scheduling if she’s installing the same app to the singular user profile under the singular account.
What I’m saying is that Zoom SHOULD NOT revoke that previous access token. Doing so is counter to Betty’s interests and intention. Betty has one user account in Zoom, but TWO user accounts in CA.
It’s legitimate for her to have two accounts in CA, and to want both to use her single Zoom account to create Zoom meetings for all of her appointments scheduled across those two CA accounts. (Incidentally, segmentation is simple because the same synced calendar used.)
I would consider this more of a bug report than a feature request!
And one that, it seems, an increase in token tolerance might readily solve.
Can that be supported again? If not, why is token tolerance increases no longer supported? And if that was removed for cause and not coming back, what hope does a feature request to solve what might be the exact same problem that that solved?
Hi @john , if I’m understanding correctly, earlier you stated that Betty is re-authorizing the app via the App Marketplace? If so, the process of de-authorizing will revoke previous access. If this is the case, this is the expected behavior.
If I’m misunderstanding, perhaps a recording or drawing of what you’re outlining would help to make sure we are aligned on the steps you’re describing.
No de-authorization is performed by Betty, and I’m not sure if “via the App Marketplace” is the way this happens (though that might be a terminology thing that I’m not clear on).
The way Betty authorizes each time is by an OAuth flow from CA to a page hosted at Zoom, and you can find a recording of the process of doing this authorization on our app’s Zoom Marketplace page, about 20 seconds into the video there: https://marketplace.zoom.us/apps/R55JqSqISgeH8BYmJPuuow
Again, no de-authorization is called for by (or indicated to) the user, it’s just an additional authorization the user is performing that is NOT meant to replace an earlier one.
What do the calls to your database look like? Are you seeing a new request for user auth from the user when they do the process for the second time via CA? I’m curious about the server side behavior.
