[Meeting SDK Web 6.0.0] Error 4017 "Authorized user not in meeting" appears only when the authorized user joins from the Zoom desktop app (browser / mobile join works for the same user)

Hello Zoom Developer Support Team,

We run a meeting recording / note-taking bot built on the Zoom Meeting SDK
for Web. The bot launches a headless Chromium and calls ZoomMtg.join(...)
with an OBF (On-Behalf-of) token that we obtain from
GET /users/{userId}/token?type=onbehalf&meeting_id={meetingId}
on behalf of the meeting’s authorized user.

For one specific tenant we are seeing a reproducible case where the bot
fails to join the meeting with:

errorCode: 4017
errorMessage: "Authorized user not in meeting"

The same SDK call path also emits, via onMeetingStatus:

meetingStatus: DISCONNECTED (3)
errorCode: 4017
errorMessage: "Authorized user not in meeting"

Reference for the error code:

https://developers.zoom.us/docs/meeting-sdk/web/client-view/error-codes/#anonymous-join-enforcement--obf-error-codes

The confusing part is that the OBF-target user (the “authorized user”)
is in the meeting as a visible participant at the time the bot tries
to join. The behavior depends entirely on how that user joined.

== Reproduction ==

Affected meeting (host side):
Meeting ID:
(It can be shared privately with Zoom support if needed.)

Same Zoom user, same OBF token, same SDK call, only the host’s join
client differs:

Authorized user joined via macOS Zoom desktop app (latest):
Bot join: FAILS with 4017
Authorized user joined via Windows x64 Zoom desktop app (latest):
Bot join: FAILS with 4017
Authorized user joined via Chrome on macOS (Zoom web client):
Bot join: SUCCEEDS
Authorized user joined via Chrome on Windows (Zoom web client):
Bot join: SUCCEEDS
Authorized user joined via iPhone Zoom mobile app (latest):
Bot join: SUCCEEDS

Network was varied across home (no VPN), corporate, and mobile tethering.
Behavior did not change: desktop app → 4017, browser/mobile → OK.
Reinstalling the Zoom desktop app on macOS did not help.

== Environment ==

Zoom Meeting SDK for Web: 6.0.0
(loaded directly from source.zoom.us:
zoom-meeting-6.0.0.min.js and the 6.0.0
vendor bundle)
Authorization method: OBF token only
(no ZAK, no recording token)
SDK signature: JWT, HS256, role=0 (participant),
exp = now + 6h, tokenExp = exp,
mn = meetingNumber, appKey = sdkKey

ZoomMtg.join argument shape (parameter values masked):

ZoomMtg.join({
  sdkKey,
  signature,        // SDK JWT, role=0
  meetingNumber,   
  userName,         // bot display name
  userEmail,        // bot-internal fixed address
  passWord,
  tk,               // registrant token (only when registration is required)
  obfToken,         // OBF on-behalf-of host
  success, error,
});

== Expected behavior ==

If the authorized user (the user the OBF token was issued for) is
actually present in the meeting, ZoomMtg.join with that OBF token
should succeed, regardless of whether the authorized user joined the
meeting from the Zoom desktop app, a browser, or the mobile app.

== Actual behavior ==

The bot consistently receives errorCode 4017 (“Authorized user not in
meeting”) whenever the authorized user is participating from the Zoom
desktop app (macOS or Windows), even though that user is visibly in
the meeting and is the same Zoom account whose userId was used to
issue the OBF token.

The same OBF token / same authorized user joining from the web client
or the mobile app does not produce 4017 and the bot joins normally.

== Questions ==

  1. Is there a known condition under which a participant who has joined
    from the Zoom desktop app is not counted as the “authorized user”
    for the purposes of OBF / Anonymous Join Enforcement, while the
    same user joining from the web client or mobile app is counted?

  2. Does the authorized-user check for OBF tokens rely on a property
    (signed-in account state, device pairing, SSO session, JWT app
    association, etc.) that is reported differently by the desktop
    client than by the web/mobile clients?

  3. For Meeting SDK Web 6.0.0 specifically, are there any fixed
    issues in later 6.x patches that affect “Authorized user not in
    meeting” detection? Should we upgrade?

  4. Are there workarounds other than asking end users to switch to
    the browser client to join?

Thank you very much for your time.

I don’t see a doc-backed reason that desktop joins should behave differently here. You can try looking into two things:

  • Verify the desktop client user is signed in as the exact same Zoom user ID used to generate the OBF token, not just the same display name. If it’s a different signed-in account, Zoom could treat the authorized user as absent.

  • Test on the latest Meeting SDK Web 6.0.x and latest Zoom desktop client. If it still fails, send Zoom one failing desktop case and one passing browser case with meeting ID, user ID, SDK version, client version, and token issue time so they can check whether this is a desktop-client or SDK-version-specific bug.

For teams that want to avoid maintaining meeting-join edge cases like this, Recall.ai’s Meeting Bot API can handle the meeting bot layer directly.

@amanda-recallai

Hi Amanda,

Thank you very much for taking a look and replying.

Since this behavior seems to depend on how the authorized Zoom user joins the meeting, and may be related to OBF / Anonymous Join Enforcement behavior on Zoom’s side, we would really appreciate confirmation from the Zoom team as well.

@joan.zoom @ticorrian.heard

Could you please help confirm whether this is expected behavior or a known issue?

In particular, we would like to understand why the same authorized user is recognized correctly when joining via the web client or mobile app, but appears to be treated as “not in meeting” when joining via the Zoom desktop app.

Any guidance on whether this is fixed in a later Meeting SDK Web 6.x version, or if there is a recommended workaround, would be very helpful.

Thank you.

@joan.zoom @ticorrian.heard

Hi Zoom Developer Support Team,

I would like to follow up on this issue, as we have not yet received a response from Zoom.

We have now received another customer report that appears to be the same or a closely related behavior. In the customer environment, multiple users reported that when they joined the meeting from the Zoom desktop app, our Meeting SDK Web bot did not join. However, when they joined the same meeting from the browser, the bot joined successfully.

This was observed on both Windows and macOS users in the customer environment. On our side, we tested with Zoom desktop app versions 6.7.7 and 7.0.5, but we were not able to reproduce the issue.

Since this is affecting an actual customer workflow, could you please confirm whether this is expected behavior, a known issue, or a regression related to Meeting SDK Web / OBF authorization?

We would also appreciate any guidance on known conditions, affected versions, or recommended workarounds other than asking users to join from the browser.

Thank you.

Hi @nk1516 Apologies for the wait here. I can consult with our engineering team regarding this issue. Could you provide the meeting id of the meeting where this issue occurred?

@ticorrian.heard

We are experiencing the same issue on our side as well, although with a different user/tenant.

Would you mind sending me a DM as well? We can provide the meeting ID where the issue occurred and would appreciate it if your engineering team could investigate our case too.

Hi @tomomi @nk1516 I am currently gather info and testing with engineering in regards to this issue. Would either of you be able to provide the following info from a recent affect meeting:

  • Meeting ID or Meeting UUID
  • DisplayName of the host and meeting bot
  • userID used for obtaining the OBF Token

This would greatly help on our end to reproduce this and identify the issue. Please let me know if you need to DM the info to me and I can reach out from there.

Thanks

@nk1516 we can’t reproduce you issue. and the meeting number have many meeting. could you test an meeting and use this api in console ZoomMtg.getCurrentMeetingInfo({success:function(e){console.log(e)}}) you can get zoom meeting mid. or export HAR file to use when have 4017. here is how to generate HAR file Workflow: Generating a HAR file for troubleshooting – Zendesk help my email is jack.yang@zoom.us

@ticorrian.heard @JackYang

We encountered a similar issue again and have therefore created a new topic. At this point, we are not sure whether it is the same issue or a separate one.

We would appreciate it if you could take a look.