After OBF rolls out, can the SDK still start meetings using only a ZAK (i.e., without an OBF token in the join flow)?
For sign-in required conferences, does the ZAK used by the SDK need to be generated for the host user specifically, or can it be any licensed user on the account?
If the user/account that owns the OBF token leaves the meeting (or is removed), does the SDK session tied to that OBF token lose access or get disconnected?
Does an OBF token behave differently or carry different privileges depending on the meeting type (standard meeting vs webinar vs other conference types)?
Hi @ehalf, thanks for the response. I read through your reply and you haven’t actually answered any of my questions because:
You caveat everything without certainty or providing additional information about what the caveats are.
There are also no links to any sources so I don’t know whether the info you shared is accurate or not.
If answering this and you’re not from the Zoom team, please include links to sources. Otherwise I can’t verify whether this information is true and where to read more. Still really appreciate you taking the time to answer though!
Can someone from the Zoom team weigh in here instead?
After OBF rolls out, can the SDK still start meetings using only a ZAK (i.e., without an OBF token in the join flow)?
To start and join a meeting or webinar for a logged in user both the ZAK+ JWT token are required
To join a meeting or webinar outside the app owner’s account, JWT + OBF would be required. see: Meeting SDK Auth
For sign-in required conferences, does the ZAK used by the SDK need to be generated for the host user specifically, or can it be any licensed user on the account?
If you want to start or host a meeting/webinar you would need to pass in the ZAK token , so ZAK must be generated for the user who will be the host. The ZAK essentially says, “The user associated with this key is the host for this specific meeting.”
If the user/account that owns the OBF token leaves the meeting (or is removed), does the SDK session tied to that OBF token lose access or get disconnected?
The meeting will continue as long as the ZAK is valid . If host wants to leave, they can assign an alternate host to any licensed user in the meeting. The OBF token owner is not a factor in the meeting being connected/disconnected here
Does an OBF token behave differently or carry different privileges depending on the meeting type (standard meeting vs webinar vs other conference types)?
OBF is used to authorize specific users and is consistent across meeting types (Meeting, Webinar)
Really appreciate the swift response and clarity on this topic @joan! I have a few follow-up questions that would be great to get your clarity on:
Say that a participant (who is not the host) grants a ZAK token to the SDK client. Can the SDK client join a sign-in required conference now?
Say an SDK client joins a call with an ZAK token (the person who grants the ZAK token is in the call already). If the person who grants the ZAK token leaves the call, is the SDK client session revoked (i.e. the SDK client is either kicked from the call or loses access to media like audio/video)?
Is the ZAK only used in the joining call flow and after unused (i.e. after joining, the ZAK has no impact on the rest of the call)?
Say that I have a service account generating ZAK tokens. With this new OBF/ZAK token update, does the service account need to be on the call for the bot to join with a ZAK Token?
I also wanted to follow up on something you mentioned earlier:
The OBF token owner is not a factor in the meeting being connected/disconnected here
I just tested this and my SDK client was removed from the meeting when the OBF token owner left the call. Can you clarify what the behavior is when the OBF token owner leaves
Hi @Joan, I was wondering if you had an update on the above? Depending on answers, I’ll need to consider looking at RTMS. Thank you!
Also I wanted to ask about the following:
Using a service account’s ZAK for all app users would not allow the app to join the meeting since that user is not actually present in the meeting. In that case the app join would fail
This implies that ZAK tokens will also operate the same as OBF tokens in terms of behavior. This isn’t documented anywhere aside from this forum post by a different Zoom staff
Is it true that the user who mints the ZAK needs to also be in the meeting while the client using the ZAK is in the meeting?
Worth clarifying here that the ZAK token is intended for when an needs to join a meeting asa authenticated user and OBF is intended for when an app needs to join witha authenticated user. Also, can I assume the ‘SDK client’ is an app needing to join the meeting as an individual use? If that is the case ..
The ZAK token can be used to start or join a meeting as a user, however, it sounds like the the SDK client would be joining would be joining on behalf of the host meaning a OBF token would be needed
Yes, ZAK is used for the join flow but an alternative host needs to assigned if the original host leaves the meeting in order for the meeting to continue. There needs to be a user in the meeting even if the person who granted the ZAK is not an alternate host can continue the meeting.
Yes, the user (the service account) associated with the ZAK or OBF must also be also in the meeting. Using a service account’s ZAK for app users will not work if the account is not present in the meeting.
To the last point “The OBF token owner is not a factor in the meeting being connected/disconnected here” once the app has successfully joined, the validity or expiry of the ZAK/OBF token does not impact its connection. The app will remain in the meeting as long as there is a host in the meeting. A refresh token might be needed if the app disconnects
Thanks @joan for clarifying, I have a few more questions that I need explicit answers for before deciding on moving to RTMS. Really appreciate your patience with me on this
Take the following scenario which only relies on a web-only flow (no Meeting SDK; participant joins via the standard meeting URL):
The host signs into our app’s web portal with Zoom OAuth
Our backend calls the Zoom REST API to generate a ZAK token for that host
When it’s time to start the meeting, our app opens the normal Zoom web client in a separate browser tab (a new, not-signed-in session) using a link that includes the host’s ZAK
The goal is for this tab to start/control the meeting as the host even if the host isn’t on their usual device or signed into Zoom in that browser
In this scenario, can the standard Zoom web client actually use the host’s ZAK to let an anonymous browser session (not signed into Zoom) join and start a meeting that normally “requires authentication to join"? Or will the web client will still enforce the sign-in requirement for this participant?
I’m trying to understand the practical difference between using an OBF token vs a ZAK token for authentication/joining. Assuming the behavior is effectively the same with this change:
both tokens are minted for a specific user (the “authorizing” user), and
both enforce the same limitation where the SDK client can only stay in the meeting while that authorizing user is present,
Then what is the functional difference between OBF and ZAK, and when is OBF actually required or recommended over ZAK?
Can you update the docs for ZAK and OBF tokens to explicitly describe ZAK token behavior?
We need to share this with our customers so they understand the intended flow and the exact conditions under which a ZAK-based SDK client is allowed to remain in the meeting vs. removed
For example, if the authorizing user leaves the meeting, the SDK client using that ZAK is also removed/kicked.
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.