I found the images on this documentation page somewhat useful. On those flow images, any point where the arrows are dotted and pointing to the left your application should be essentially just waiting for a callback. This is when the message passing is essential for the application to function, as otherwise those callbacks will never be called.
In your case, calling the message passing loop after calling SDKAuth should let you authorize successfully, provided you have given the SDK a callback. The simplest way to make this work is:
- Initialize the SDK by calling InitSDK with valid params
- Get an authService by calling CreateAuthService
- Give it your event handler (which is a class that extends IAuthServiceEvent) by calling the authService’s SetEvent function
- Call the authService’s SDKAuth (with a valid JWT)
- Spin in the message passing loop until the callback has been called (your callback could break the loop somehow once it’s successfully called)
A similar order of events happen for other parts of the SDK as well (e.g. logging into a Zoom account), so I used a sort of state machine where my application had active states where it would perform actions (e.g. sending out auth or login requests) and passive states where it would simply allow the message loop to continue because it had to wait for a callback (e.g. when waiting for auth or login).
Hopefully this description is enough to at least get you a successful auth; things made a lot more sense for me once I finally figured out this problem.