Updates to Meeting SDK Authorization

[JenBrissman (Jen)]

Hi @AvinashUmmagani - I am still seeing it - does this link work for you? Requiring authorization for meetings joined outside of an app's account

[joan.zoom (Joan)]

@thinktapwork

I had posted this on November 20th and haven’t heard back. Bumping it.

I was curious to get your thoughts on Apple’s App Review Guideline 5.1.1 (v) regarding Account Sign-In:

Regarding Apple’s App Review guidelines on sign in , we understand the concern. Because Zoom is the provider, the OBF/ZAK requirement is a technical dependency. When submitting to Apple, you should state that the login is not for ‘user tracking’ but rather for security-mandated handshake required by the Zoom Meeting SDK to facilitate cross-domain communication. As OBF does require OAuth login to join as a participant in meetings outside their own account , note that RTMS authorizes at the Account level.

[joan.zoom (Joan)]

@ianb

As part of our online platform, we develop online web conferencing solutions for clients that utilise various third party providers. In the case of Zoom, we utilise a ZAK token from our account to allow users of our web app to connect anonymously to a secure Zoom meeting or webinar created in a clients account. Will this no longer be possible? Secondly, how can we test this behaviour before it is planned to be enforced on 23rd February 2026?

Hello @ianb

Our goal is to ensure that the ‘bad taste’ is replaced by the ‘long-term trust’ of a secure platform. We aren’t just factoring in the licenses sold but also the long-term reputation of the developers. We are here to provide guidance and support needed to make this transition a success including for upcoming scheduled meetings.

For you initial question - correct, from February if the meeting is “external” (hosted outside your account), the joining app must be attributed to a user who has authorized the app. The ZAK token is tied to a specific Zoom user account and will not allow the anonymous join. Please also refer to the FAQs for more on OBF vs ZAK token and which would be the appropriate solution for your use case. For testing, before calling the join() function, the app can determine if it is in an Authorized State: Has Token: the user has completed OAuth and the app holds a valid OBF/ZAK token or No Token: the user is anonymous. A wait/try logic can be used.

Hope this helps

[nk1516]

Hi @JenBrissman

Thank you for the clarification. I understand that there is currently no flag or setting to simulate the future “anonymous join blocking” enforcement.

Based on your advice, we proceeded with a PoC using Web SDK 5.0.0.

Our PoC Results: As you explained, since the enforcement is not yet live, the following scenarios—which should eventually fail—resulted in a successful join (treated as a standard anonymous join) in our testing:

• Joining with no OBF token (empty).

• Joining with an invalid (dummy string) token.

• Joining with an expired token.

• Joining with a token containing a mismatched meeting_id.

However, we did confirm that when “a valid OBF token is provided, but the authorized user is not in the meeting,” the join correctly failed, returning join error code: 1.

My Question: Since we cannot reproduce the failure state for the “missing/invalid token” scenarios today, we are unable to determine exactly how to handle these specific errors in our code.

Could you please provide the exact Error Codes and Event Payloads that the Web SDK will return for the following scenarios after the enforcement begins on February 23, 2026?

1. When no OBF token is provided.

2. When the provided OBF token is invalid or expired.

Will these scenarios also return a generic join error code: 1, or will they return a specific error code (e.g., 3xxx) or a specific reason string?

Having the specific error specifications (schema and values) will allow us to implement the necessary fallback logic now, even if we cannot trigger the errors in the live environment yet.

Thank you again for your support.

[Netali]

Hi
I have some questions regarding the OBF .
I tried to create a test application in my account and gave the right scopes . then i tried to use the official web sample in git and add in the code the obf token while joining the meeting .

because this app is not published i can’t try to access an external meeting , but when i’m giving it a wrong OBF token i still can join the meeting . I guess because it is test app in the same account of the meeting .

my purpose is to see if we have changes in the user experience - what other participants see when we use the OBF token to enter a meeting , and if we can still define the name of this participant.

[Netali]

Hi
anyone can help with my questions above ?

also i need a way to block the join for anonymous join as it will be after Feb 23rd , to make sure everything defined fine and we are good with our new deployments .
any idea if we can do it ?

as i said tried to enter a not valid OBF token for an internal meeting and still could join the meeting .

[JenBrissman (Jen)]

Hi @nk1516 -

We have these two specific strings that should be more helpful than a generic error code. I am looking into if we might have more available to support developers.

MeetingSDK Web
4012 = This join flow is not supported, please join the meeting with a Zoom Client or contact your meeting host.
4013 = Your obfToken is invalid, please check your obfToken.
ZoomMtg.inMeetingServiceListener(‘onMeetingStatus’, function (data){});

Thank you for reaching out to us. We are here if you have more feedback or questions. I will follow up here if I find out more about additional error messages.

[JenBrissman (Jen)]

Hi @Netali

I can help clarify what you are seeing.

Regarding the OBF token behavior:
When you are testing with an unpublished app in the same Zoom account as the meeting, Zoom is more permissive. If the meeting belongs to the same account, Zoom can fall back to standard internal authentication even when the OBF token is invalid or missing. That is why you are still able to join the meeting with a wrong OBF token. This does not reflect the behavior you will see for external meetings or cross account scenarios.

To properly validate OBF enforcement, you need one of the following:

• Join a meeting hosted by a different Zoom account
• Use a published app or a production app with external access enabled

Only in those cases will an invalid OBF token correctly block the join.

User experience and participant name:
From a user experience perspective, other participants do not see anything special indicating OBF usage. The participant appears like a normal meeting participant. You can still control the display name using the name parameter when joining, unless restricted by meeting settings such as authenticated users only or enforced naming policies.

Blocking anonymous join after Feb 23:
To prevent anonymous joins, you should enable authenticated meeting requirements. Specifically:

• Enable “Only authenticated users can join meetings”
• Optionally restrict authentication to users signed in to Zoom or users from specific domains

Once this is enabled, users without valid authentication or a valid OBF token in supported flows will not be able to join. This is the correct way to validate your upcoming deployments and ensure anonymous access is blocked.

The behavior you observed with invalid OBF tokens joining internal meetings is expected during testing and should not be treated as a deployment issue.

Hope this helps!

[thinktapwork (Jeremy Provost)]

We would like to know the following:

• Is there a create user flow, similar to the current sign in flow? i.e., a page that we would be directing users to from within our app where they can create a Zoom user account and then return a valid ZAK back to the app.
• Is there a programmatic flow for creating a Zoom user account for a user through the API? In other words, we would handle the front-end but the user would be creating a Zoom account.
• Is there an API or other web flow for deleting a user account?

[BZone (Barys)]

Could someone help us with our question related to new authorization requirements: Existing accounts hierarchy and New Authorisation Requirements (OBF and ZAK tokens)

[thinktapwork (Jeremy Provost)]

Bumping this as we haven’t heard back and the deadline is fast approaching.

We would like to know the following:

• Is there a create user flow, similar to the current sign in flow? i.e., a page that we would be directing users to from within our app where they can create a Zoom user account and then return a valid ZAK back to the app.

• Is there a programmatic flow for creating a Zoom user account for a user through the API? In other words, we would handle the front-end but the user would be creating a Zoom account.

• Is there an API or other web flow for deleting a user account?

[blessing]

@JenBrissman We are currently testing with the latest Web Meeting SDK version 5.1.0 and are unable to trigger the OBF token enforcement errors.

Even when we intentionally use an invalid/incorrect OBF token, the SDK still allows joining the meeting without throwing an error. We expected the SDK to enforce token validation and block access when the token is wrong or when the user is not part of the meeting.

Our questions are:

1. Is there a recommended way to simulate OBF token enforcement errors using the Web Meeting SDK?

2. For example, how can we reproduce scenarios such as:

   • Supplying a wrong/expired OBF token, and

   • OBF enforcement when the user is not in the meeting

We want to confirm our validation logic and ensure that the SDK handles unauthorized access as expected.

[JenBrissman (Jen)]

Hi @blessing -

This is a very reasonable thing to want to test ahead of the enforcement date.

The short answer is that there is no special flag, account setting, or sandbox mode today that allows you to simulate future anonymous join enforcement early.

The good news is that the behavior you need to build against is already live today through the OBF policy in the Meeting SDK for Web. From the SDK’s perspective, the logic is binary:

• If the app provides a valid OBF token and is not exempted, the join proceeds.
• If the app does not provide a valid, non expired OBF token, the join attempt is rejected.

There is no separate “anonymous join blocked” simulation because enforcement is effectively the absence of a valid token. You can trigger the same failure state today by attempting to join a meeting using the Meeting SDK for Web without an OBF token or by supplying an invalid or expired one.

There are helpful error codes for testing this functionality here: Meeting SDK - web - client view - Error codes

In this scenario, the Meeting SDK for Web will fail the join operation before the user enters the meeting. You should expect a join failure surfaced through the SDK’s join error callbacks, not a user_leave event after a successful join. This is the point where you can implement wait, retry, or user messaging logic.

From an implementation standpoint, the recommended approach is:

• Build assuming OBF is required.
• Test join attempts with no token, an invalid token, and a valid token.
• Handle the join failure path gracefully before the user ever enters the meeting.

That same logic will continue to work after March 2, 2026 when enforcement becomes mandatory.

Hope this helps clarify how to test the behavior today, and thanks again for planning ahead on error handling.

[scrum (IZWF)]

@JenBrissman if enforcement is already in place, and Meeting SDK for Web already rejects join requests that are subject to OBF requirement if no OBF token is provided, what will change on March 2nd?