Updates to Meeting SDK Authorization

Meeting SDK
21

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

1 Like
22

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.

23

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

1 Like
24

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.

1 Like
25

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.

26

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 .

27

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){});

auth error
auth error1753×394 92.4 KB

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.

28

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!