Zoom IDs repeating

Description:
It has come to my attention that, in the course of configuring a custom API to store information about our Zoom sessions, we are seeing that different users in our org using our subscription account to access our custom video chat solution may end up with the same Zoom ID over different sessions. We have not seen this in the same session, but we have called client.join() with different signatures, different usernames, to different topical rooms from different browsers AND computers over the course of days and have seen a few IDs be repeatedly (but not concurrently) assigned.

We raised this notice before but we were instructed that it was highly unlikely. This “recycling” however has been observed by our team recently again. We have seen it with more than one ID - in particular there seems to be one ID that is extremely likely to be reassigned and another ID that usually comes up for the second joiner.

While it may be difficult to reproduce, a possibility is that some aspect of the system that generates IDs for a particular account’s users is somewhat deterministic and is prone to recycling. It may be unlikely to happen in a system with constant use, but could pop up more frequently if the account in question returns often to a zero-active-user state & is frequently starting at the beginning of an algorithm of ID assignments.

Which Web Video SDK version?
1.1.0, but also 1.0.3 exhibited this.

To Reproduce
You will need to set your software to allow end users to see their own ID and, perhaps, the participants in a meeting. The frequency is intermittent, but I’ve seen it fairly consistently.

Using an account that is not in use, simply have 2-3 people join a meeting and take note of their assigned IDs. Allow everyone to log off.
Repeat an hour later (ensuring that the account is not used by others in the meantime) and compare the second-time assigned IDs to the first batch. You may use entirely different connection information, including different user names and a different topic.

We have sometimes seen it as soon as 15 minutes.

Devices:
Observed on heterogenous systems. Most are Ubuntu 20.04 LTS, running Chrome 91.0.4472.114 (64bit) on assorted PC hardware. Can similarly occur with Firefox 89.0.2 (64-bit) on the same OS/hardware. One of our rotating clients is on Win10 with the same Chrome version as above.

Additional context
It’s worth restating that this isn’t a “bug” to us, but clients or secondary APIs cannot assume that there is a practically zero probability of any two users (in different meetings at different times) being assigned the same ID, and cannot depend on it. Any custom client user tracking system must assume that User 2 can get a re-used Zoom ID after User 1 has been assigned it for a different connection (but not concurrently). It may not happen in certain scenarios, but we’re unclear if/why there are exceptions. We have made sure that none of our logic depends on Zoom IDs being uniquely assigned and non-repeating. The repeat-ID tendency has not prevented any of our users from using client.join() successfully.

Hey @brianWD

Thanks for your feedback.

ID you mentioned in the post is userId, which gained via client.getAllUser()?

Don’t worry userId of each session is isolated and one-time, therefore, different sessions may have the same userId.

Thanks
Vic

Correct, the in-call ID assigned by client.join() or that can be later retrieved in client.getAllUser() is the id that I am talking about, and this is in SDK versions prior to 1.1.3 where other identification fields have been introduced. I concur that my findings are that each userId in a session is unique/one-time and that alike IDs have only been observed in different sessions.

(For anyone else reading this, this will not matter for Zoom connections but it might matter if you are saving the Zoom ids of clients to link other kinds of things together. You cannot identify your own clients uniquely by Zoom session id across different sessions - Zoom IDs seem to become recycleable very soon after a user disconnects. We had to rule out that we didn’t have a logic bug in storing User session information when we saw some of our debug info showing tables with repeated Zoom IDs between users who joined and left at different times)

Hey @brianWD ,

We did recently release session_key and user_identity fields so you can pass in a unique identifier to help track your sessions and users.

https://marketplace.zoom.us/docs/changelog#publications/video-sdk-web-v1-1-3

Thanks,
Tommy

how to use user_identity ? Documentation not updated .

Hey @noobchen ,

Checkout the docs here: https://marketplace.zoom.us/docs/sdk/video/web/build/signature#optional-parameters

You can pass it into the signature.

Thanks,
Tommy