How Will ZAK-Based Joins Work After OBF Rollout in the Client SDK?

Meeting SDK
11

Hello @Jer, see below and please note we also have weekly office hours if you need additional guidance

For the web client flow scenario you described..

can you confirm if you are currently using Create a meeting API to create a meeting on behalf of a host?

  • Note that the standard Zoom web client does not accept a ZAK token as a substitute for user authentication in a normal browser session. A ZAK is designed for SDK or API‑based joins, not for direct use in the public web client. When a meeting is configured to “require authentication to join,” the web client will still enforce sign‑in for any participant who is not already authenticated through Zoom. Passing a ZAK in the URL will not bypass that requirement.

  • ZAK tokens are valid only within SDK or REST API contexts where the app explicitly authenticates on behalf of a user. The web client itself expects a signed‑in Zoom session and will not treat a ZAK as proof of identity.

Practical difference between using an OBF token vs a ZAK token for authentication/joining.

  • ZAK represents a specific Zoom user and is issued after that user authorizes the app via OAuth. It allows the SDK to start or join meetings as that user, including hosting or joining meetings that require authentication.

  • OBF token represents the app, not a user. It is used when the SDK joins as an automated participant (for example, a bot or recorder) or when joining meetings outside the app owner’s account.

  • After the OBF rollout (February 23rd), the following will apply:

    • To start or join a meeting/webinar as a signed‑in user, the SDK must use ZAK + JWT.
    • To join as an app (for external meetings or automated roles), the SDK must use JWT + OBF.
    • ZAK‑only joins will no longer be sufficient.

    TLDR:

    • Use ZAK when the SDK acts as a specific user (e.g., the host)
    • Use OBF when the SDK acts as the app itself or joins meetings outside your account.

Can you update the docs for ZAK and OBF tokens to explicitly describe ZAK token behavior?

  • We will share feedback with our documentation team to mention ZAK tokens are user‑scoped and valid only for SDK/API contexts, not for direct web client joins. and OBF tokens are app‑scoped and required for automated or cross‑account joins.

    • Meeting continuity depends on ZAK validity, not OBF ownership.

Customer understanding of intended flow and the exact conditions under which a ZAK-based SDK client is allowed to remain in the meeting vs. removed (ex authorizing user leaves the meeting, the SDK client / ZAK behavior)

  • If the user associated with an OBF token leaves, the meeting continues as long as the ZAK for the host remains valid. The OBF token’s presence or absence does not affect meeting continuity.

  • For ZAK‑based sessions, the SDK client remains connected as long as the ZAK is valid. The meeting only ends or transfers host control if the host leaves without assigning an alternate host. The SDK client using that ZAK is not automatically removed when the authorizing user leaves unless the meeting itself ends or the ZAK expires

I hope these addresses your questions above. if not, please I encourage you to join our weekly office hours (please see link for times) and you can share any additional details and follow up questions so we can get you and your team the answers you need.