I'm either setting this up wrong, or oauth-s2s account id is getting mangled

[HS-Dave]

Hi! I am migrating our existing JWT implementation to OAuth server-to-server. I created an OAS2S app in zoom, grabbed the details, setup a bunch of scopes (it would be cool to have a list of which scopes zoomnet needs for which services :) ) and activated it.

Whenever I attempt to use a client created with OAuthConnectionInfo.ForServerToServer using the apps account id/client id/client secret it gives me an exception: Exception User does not exist: -6uh*****************w.

Weird stuff: if I deactivate the app in zoom then the exception changes to app is disabled. It finds the app just fine. The moment I activate it, it says user does not exist.

Maybe this is my fault - but one thing I noticed is the exception outputs the account id and there is a period on the end. No other exceptions i've received in my logging have a period on the end and im wondering if its somehow getting added to my account id? I have output the account id to log before creating the connection info and zoom client, no period there.

Maybe just zoom puts a period at the end of that one message, but i'm running out of ideas :D any thoughts?

[Jericho]

I am not too too alarmed by the extra period. My guess is it's simply added to the error message but to be sure, you should use a proxy tool to visually inspect the request being sent to Zoom and their response and confirm everything is being sent as expected. I personally like Fiddler Classic but you can use other tools as well and you configure ZoomNet to send request through this proxy like so:

var clientId = Environment.GetEnvironmentVariable("ZOOM_OAUTH_CLIENTID", EnvironmentVariableTarget.User);
var clientSecret = Environment.GetEnvironmentVariable("ZOOM_OAUTH_CLIENTSECRET", EnvironmentVariableTarget.User);
var accountId = Environment.GetEnvironmentVariable("ZOOM_OAUTH_ACCOUNTID", EnvironmentVariableTarget.User);
var connectionInfo = OAuthConnectionInfo.ForServerToServer(clientId, clientSecret, accountId);

var proxyPort = 8888; // By default Fiddler Classic uses port 8888; if you use another proxy tool you'll have to figure out which port it uses
var proxy = new WebProxy($"http://localhost:{proxyPort}");

var client = new ZoomClient(connectionInfo, proxy);

I am guessing you are getting this error message when invoking a method that requires you to specify a user id. Something along the lines of:

var myUser = await client.Users.GetAsync("6uh*****************w", cancellationToken).ConfigureAwait(false);

Maybe there's a slight typo in the user name?
Maybe the userId is associated with a different account that the one where your S2S app has been added?

These are just guesses on my part. It's impossible for me to know why Zoom is rejecting the userId. To eliminate these two possibilities you should try replacing the userid with Zoom's special keyword: me. Like this:

var myUser = await client.Users.GetAsync("me", cancellationToken).ConfigureAwait(false);

Let me know if any of this helps.

it would be cool to have a list of which scopes zoomnet needs for which services

ZoomNet doesn't need any scopes, it's the Zoom API that dictates which scope are necessary for each endpoint. Maybe you mean that the ZoomNet XML comments should document the scopes for each resource method? By copying and pasting from the Zoom documentation maybe? That's not unreasonable but sounds like a tedious task though, not sure I'm interested in signing up for that but I would gladly accept a PR 😁

[HS-Dave]

thanks for responding!

the scopes thing is an assumption on my part, when setting up an OAuth Server to Server app you are presented with a place to add the scopes you require to allow api access:

and from the description it looked like I would need the correct scopes to allow zoomnet to make the required API requests. Is this false? I just added whatever looked relevant, can I just not select any scopes?

I will try fiddler to double check the data passing through, good shout. The weirdness to me is this is an existing and mature zoom integration for a client that is live and deals with 100s events/participants. All i'm trying to do is switch from JWT to OAuth Server to Server as per readme before the deadline at end of the month.

The endpoint being called here is actually CreateWebinar. The original code looked like:

        public async Task<long> CreateWebinar(ZoomConnectionDetail connectionDetails, ZoomWebinar zoomWebinar)
        {
            using (var zoomClient = new ZoomClient(new JwtConnectionInfo(connectionDetails.ApiKey, connectionDetails.ApiSecret)))
            {
                var webinarResult = await zoomClient.Webinars.CreateScheduledWebinarAsync(
                ....stufff....
            }
          }

and this worked fine. my refactor involved storing the auth type on our settings model and creating a helper to return the right client:

public ZoomClient GetZoomClient(ZoomConnectionDetail connectionDetails)
        {
            switch (connectionDetails.AuthType)            
            {
                case ZoomAuthType.JWT:
                    Console.WriteLine("For Unit Test: JWT");
                    return new ZoomClient(new JwtConnectionInfo(connectionDetails.ApiKey, connectionDetails.ApiSecret));                    

                case ZoomAuthType.OAuthServerToServer:
                    _logger.Log(LoggingLevel.Trace, $"zoom connection service - attempting to create oauth token for {connectionDetails.ZoomUserId}");                    
                    var connectionInfo = OAuthConnectionInfo.ForServerToServer(connectionDetails.ApiKey, connectionDetails.ApiSecret, connectionDetails.ZoomUserId);
                    return new ZoomClient(connectionInfo);

                default:
                    throw new Exception($"invalid value on zoom connection details auth type");
            }
        }

and the create webinar became:

 using (var zoomClient = _zoomConnectionService.GetZoomClient(connectionDetails))
            {
                var webinarResult = await zoomClient.Webinars.CreateScheduledWebinarAsync(
...stuff..

which.. breaks.. wait. it does pass the user id, and the user id field for oauth i've repurposed to be account id.. HECK, sorry i just used you as a rubber duck. I'm guessing you still pass the user login email that owns the app to these end points and not the new account id?

gahhh!

i'll still post reply for the clarification on scopes but i think we just found the problem! sorry!

[Jericho]

from the description it looked like I would need the correct scopes to allow zoomnet to make the required API requests. Is this false?

It is true that you must select the scopes that are appropriate for the endpoints you intend to invoke but I just want to be clear that the fact that you use ZoomNet (or any other 3rd party C# library for that matter) is completely irrelevant to which scopes you need to select when you configure your OAuth app. What matters is which Zoom API endpoints are you going to invoke. That's what dictates which scopes you need to select.

Maybe I'm reading too much into what you said, but it gave me the impression that you think there are some scopes that are necessary specifically for ZoomNet. The point I'm trying to make is that the C# library you use has absolutely no bearing on the scopes you need.

I just added whatever looked relevant, can I just not select any scopes?

You can't just randomly pick "whatever looks relevant". You need, at a minimum, to pick the all scopes that are needed (according to Zoom's documentation) to use the endpoints that your C# code will invoke.

For instance, in the code sample you posted above you attempt to create a webinar. Therefore you need to select the scopes that Zoom says are necessary to invoke the "Create Webinar" endpoint (which are webinar:write and webinar:write:admin according to Zoom's documentation). If your C# code also attempts to retrieve an existing webinar, you would need to also select the scopes which Zoom says are necessary to invoke the "Get Webinar" endpoint (which are webinar:read:admin and webinar:read according to Zoom's documentation), and so on.

I hope this makes sense.

[HS-Dave]

It makes perfect sense :) To be clear, i'm not saying there is a scope to allow use of zoomNet, I mean to perform the actions zoomnet performs on my behalf. I clearly think of my interactions with zoomnet wrong as you consider them to be directly equivilent of zoom api interactions whereas I have had the mindset of I am interacting with zoomnet, it's interacting with the api on my behalf and I havn't double checked if that is identical to me making the same call or not.

I know, especially when it comes to authentication and refresh tokens etc you handle lots in the background that we don't have to see or worry about. I did not know if CreateWebinar is a direct map to a zoom api endpoint or if you look internally at the details of that webinar and call one or multiple end points based on webinar details etc.

This is a me problem, not a you :)

I assure you scopes were not picked at random, there was an ounce of common sense in it! :)

Again, thank you for your time!

[Jericho]

the actions zoomnet performs on my behalf

Yes, this is a very nice way to put it. ZoomNet hides some of the complexities from you but in the end it simply invokes the API endpoints on your behalf.

I havn't double checked if that is identical to me making the same call or not.

All the methods in ZoomNet correspond to a Zoom API endpoint. For example:

• Webinar.Create in ZoomNet corresponds to the "Create Webinar" endpoint
• Meeting.Update in ZoomNet corresponds to the "Meeting Update" endpoint
  ... etc.

I see your point about the possibility of ZoomNet invoking more than one endpoint in a given method and it's certainly something I would do if the result was to hide some of the Zoom API details or to make developers' life easier but I can't think of an instance where I did that (my memory has failed in the past so it's possible such a situation exists and I don't remember, but I doubt it).

there was an ounce of common sense in it!

hahaha! Well said!

[Jericho]

Completely unrelated to this discussion:

A detail in the code samples you posted caught my eye. You seem to instantiate short-lived ZoomNet clients like in these two instances:

 using (var zoomClient = new ZoomClient(new JwtConnectionInfo(connectionDetails.ApiKey, connectionDetails.ApiSecret)))

using (var zoomClient = _zoomConnectionService.GetZoomClient(connectionDetails))

I strongly advise against doing this because the ZoomNet client relies on Microsoft's HTTP client to dispatch the requests and constantly instantiating new HTTP clients can lead to socket exhaustion under heavy load. I discussed this situation here. In my opinion, one of the best explanation of the problem with short-lived HTTP clients was written by Simon Simms back in August 2016 but there are many other similar articles you can find with a quick Google search.

My recommendation is to do one of two things:

1. instantiate the ZoomNet client once and reuse it throughout your app. A side-benefit of this scenario is that your ZoomNet client will request a token when you make your first API call, save it in memory, reuse it when you make subsequent API calls, refresh it before it expires, etc.
2. instantiate the HTTP client yourself, save it so it can be reused throughout your app, and pass it to the ZoomNet client's constructor with each new instance. In this scenario, it doesn't matter that your ZoomNet clients are short-lived because you reuse the HTTP client. The down side however, is that you lose the automatic token management logic I explained above. If you want the token to be preserved and subsequently reused, you are responsible to write the code to do that (it's not too complex, but definitely something you must consider).

Personally, I think option 1 is simpler. But if you choose option 2 you have two options as far as token management is concerned:

• Either you allow ZoomNet to request a new token whenever a new instance of the ZoomNet client is created. Some people have the opinion that this is not a good idea because you end up requesting a lot of tokens which takes time and is a waste of resources.
• or you take advantage of ZoomNet's OnTokenRefreshed delegate to save the token to a repository of your choice whenever a new one is obtained. This allows you to retrieve the token from your repository and pass it to the OAuthConnectionInfo.ForServerToServer method when you subsequently instantiate a new ZoomNet client. This is a more "hands-on" token management approach that mimics ZoomNet's token management.

Or you can decide to ignore my recommendation and hope that you never face the dreaded socket exhaustion problem! 😜