SSO login fails on first attempt

Description
We are finding the SSO Login fails often on the first call to the SDK. Fail Reason is OtherIssue
Sending a repeat request with the same token causes the same failure.
Repeating the exact same process to generate a new token and sending it works perfectly fine and succesfully logs in.

Which Desktop Meeting SDK version?
Windows 5.7.6.1072

To Reproduce(If applicable)

  1. GenerateSSOLoginWebURL
  2. Scrape token from webpage
  3. Pass Token into SSOLoginWithWebUriProtocol

Hi @brandon1,

Can you please try updating to the latest version and testing again?

Thanks!

Hi @jon.lieblich

I have been looking over the latest SDK and it looks like the email/password login is removed.
This doesn’t really work for our use case as our users often use either method of signin.
If we are being forced into OAuth for signin, is there a recommended usage that we can adhere too?

Hi @brandon1,

While we do not have comprehensive documentation on how to implement OAuth on each individual platform yet, we do have an overview available that should help get you started. If you have any specific questions on how to implement this, we can definitely help clarify. :slightly_smiling_face:

Thanks!

Hi @jon.lieblich

I have picked up version 5.9.3.3191 and modified the demo application.
I have it generate a url with GenerateSSOLoginWebURL,
I copy that URL into a browser, find the uri for that opens the Zoom application (zoommtg://domain.zoom.us/sso?token=…)
I copy and paste that domain and supply it to SSOLoginWithWebUriProtocol.
I am finding my OnLoginRet always returns LoginStatus = loginFailed and LoginFailReason = otherIssue.

Hi @brandon1,

If you are migrating to use OAuth for user authentication, this approach will also allow users to select SSO. This approach will not require you to use any of the SSO-specific methods in the SDK.

Thanks!

I misunderstood I suppose about the OAuth.
I am just trying to get the SSO usage of the SDK working.

Hi @brandon1,

The recommended approach for SSO is to use OAuth and have the user select the SSO option when logging into Zoom.

Thanks!

So what methods are you supposed to use in the sdk for an SSO login?

Jon

We are using Zoom SSO login with SDK in our production code and it no longer works. You never sent out any warning that the SDK support for SDK SSO is being removed. We need this fixed as soon as possible.

We have in-production customers unable to use their SSOs because of this bug.

Don

Hi @brandon1,

If you use OAuth, you don’t need to make any SSO-specific method calls. There will not be any difference from the perspective of your implementation based on what type of login the user selects. The only thing that matters is that they complete authentication and you get an access token.

Thanks!

Hi @don_ucw,

Sorry to hear you’re running into issues with your existing implementation. Can you please provide a little more information around what exactly is going wrong?

Thanks!

Hi @jon.lieblich

I have been able to make a small sample that gets the ZAK.
What I am wondering now, how do I provide that ZAK to the SDK so it realizes the user is logged in?
I don’t see anything in the Auth_Service_Wrap to imply it takes a ZAK.

Hi @brandon1,

The SDK does not retain any state related to user authentication via ZAK after leaving a meeting. You need to provide it when you join/start a meeting through the userZAK field.

Thanks!

Hi @jon.lieblich

This is getting confusing, as going with OAuth appears to break a considerable amount of functionality in the SDK.
We had usage of a number of different settings interfaces for a user when they were logged in before.
Like with IGeneralSettingContext, IVideoSettingContext, IAudioSettingContext, and IRecordingSettingContext.
We use these interfaces so our users can configure their settings from our application.

But it is sounding like we cannot get the SDK to have “context” of the current user anymore.
How are we supposed to use the different setting interfaces like I listed above with a ZAK and OAuth?

Hi @brandon1,

Can you provide some specific details around what functionality is breaking when switching to use a ZAK? You should still be able to modify settings through the SDK regardless of the type of user authentication. If there is a specific sequence that doesn’t work when using a ZAK, we can definitely investigate updating the SDK to support it.

Thanks!

Hi @jon.lieblich

I had a misunderstanding about the nature of settings within the SDK and had assumed they applied to the users account. It seems instead the settings will apply for any user that uses the SDK, is that correct?

While looking at upgrading to an OAuth SDK app, our organization already has an SDK app that has existed for quite a few years now.
We don’t see an option for upgrading our current app or how to create an additional SDK app.
We don’t want to outright remove our current legacy sdk app as not all our users currently using our application would lose access; instead we want to create a new app that we can use when we release an update. Question is, how do we create a second SDK app to exist alongside our current existing one?

Hi @brandon1,

The scope and impact of a setting can vary depending on which specific setting you are referring to. Some of them are specific to the current SDK instance, while others may map to an account-level or meeting-level setting.

If you want to migrate to an SDK + OAuth app, you can do so by upgrading your legacy SDK app directly. Your existing SDK credentials will still be valid. The only difference is that there will be additional credentials available under your existing app for OAuth. Since a Marketplace account can only have one set of SDK credentials, you would need to either convert your existing app or create a new account.

Thanks!

How do we upgrade our legacy SDK app?
And will doing so disable login by email/password or SSO that our customers currently using while we work on an update using OAuth?

I am curious what settings are Account-level and accessible from the SDK? That sounds like something where a user would need to be logged in to the SDK to modify them.

Hi @brandon1,

How do we upgrade our legacy SDK app?

When you login and view your legacy SDK app on the Marketplace, you should see a dialog prompt you to upgrade to the new app type. You can check whether or not your SDK app was already upgraded based on whether there is an “OAuth Credentials” section on the “App Credentials” tab.

And will doing so disable login by email/password or SSO that our customers currently using while we work on an update using OAuth?

The app type will not have any impact on existing functionality, so older versions of the SDK can still utilize whatever features are available in that version as long as that version is supported.

I am curious what settings are Account-level and accessible from the SDK? That sounds like something where a user would need to be logged in to the SDK to modify them.

There are many settings that are specific to accounts or groups, so we can’t really list all of them out. Generally speaking, the Zoom Support page is going to be the best resource for checking the scope of specific settings. Those articles are more focused around the Zoom client, but the SDK should behave similarly to the client in most scenarios.

Thanks!