Bug: Desktop Client generates malformed OAuth redirect URL (& instead of ?) — affects ALL Marketplace apps

Zoom Apps
1

Summary

The Zoom Desktop Client constructs a malformed redirect URL when a user who is not logged into the Zoom web portal clicks “Add” on any Marketplace app. The continue parameter is appended with & instead of ?, producing a URL with no valid query string delimiter. This results in a 400 error in the browser.

This is a Zoom client-side URL construction bug — it is not specific to any individual app or developer integration. We have confirmed it affects first-party and third-party apps alike (Google Drive, Workday, our own app, etc.).

Steps to Reproduce

  1. Log out of Zoom on the browser (zoom.us).

  2. Log in to the Zoom Desktop Client using Google OAuth or Apple OAuth (SSO).

  3. Open the App Marketplace inside the desktop client.

  4. Search for any app — e.g., “Google Drive”, “Workday”, or any other Marketplace app.

  5. Click the “Add” button.

  6. A browser window opens with a malformed URL → 400 error.

Expected Behavior

The desktop client should construct a valid URL with ? as the query string delimiter:
https://zoom.us/google_oauth_signin?continue=https%3A%2F%2Fzoom.us%2Foauth%2Fauthorize%3Fclient_id%3D…

Actual Behavior

The desktop client uses & where ? should be:

https://zoom.us/google_oauth_signin&continue=https%3A%2F%2Fzoom.us%2Foauth%2Fauthorize%3Fclient_id%3D…

Since there is no ? anywhere in the URL, the server treats the entire path as a resource path rather than a path + query string, and returns a 400 Bad Request.

Manually replacing &continue= with ?continue= in the browser address bar produces the correct behavior — the user is taken to the Zoom sign-in page and then redirected to the app’s OAuth consent flow.

Scope of Impact

  • All Marketplace apps are affected — this is not app-specific.

  • All users who authenticate to the Desktop Client via Google or Apple SSO but have not separately logged into zoom.us in their browser.

  • Both google_oauth_signin and apple_oauth_signin paths exhibit the same behavior, suggesting the bug is in shared URL-building logic within the desktop client.

Workaround

If the user logs into zoom.us in their browser before clicking “Add” in the desktop client, the OAuth redirect is bypassed entirely and the app installs correctly.

Environment

  • Zoom Desktop Client Version: 6.7.7 (76486)

  • OS: macOS

  • Tested apps: Google Drive, Workday, Microsoft 365

Why This Matters for Developers

This bug creates a broken first-run experience for any Marketplace app whose users authenticate via Google or Apple SSO on the desktop client. As app developers, we have no control over the URL that Zoom constructs when the user clicks “Add” — this is entirely within Zoom’s client-side code. Users hitting a 400 error on install will assume the app is broken, leading to abandonment and negative perception of our apps.

We’ve filed a support ticket (TS2256244) which has been escalated, but wanted to raise visibility here in case other developers are seeing the same issue or can confirm.

Has anyone else encountered this?