This post explains the OAuth2 flow for desktop apps.   It begins by calling OAuth2.StartAuth.

The oauth2.StartAuth method does two things:

1) Returns a URL that should be displayed in a browser.
2) Starts a background thread to receive the redirect callback from the browser.

The flow of control is like this:
1) The browser (popped up and displayed by the application) automatically navigates to the URL provided by StartAuth.
2) The user interactively authorizes the access.   In doing so, the response sent back to the browser is a redirect to http://localhost:<someport>/
3) The browser receives the response, and redirects to the http://localhost:<someport>/
4) The background thread is the thing that is listening at <someport> and receives the response, and then your OAuth2 is completed.

The redirect must go to http://localhost:<someport>/.   It must be localhost, and it cannot be “https”.   If you defined your application’s redirect URL to a web address such as “…”, then the background thread is just sitting there waiting for the callback, which never happens (because it went to your web server).

Note 1: For Microsoft API’s such as for OneDrive, make sure that your App on Microsoft Developer Dashboard, inside Authentication, Redirect URIs,  set the app type to Web (not public client).   Your desktop app is acting as a web server when receiving the single redirect request.  (Also, .NET apps may need to add NSExceptionAllowsInsecureHTTPLoads YES in the info.plist.)

Note 2: If using “http://localhost:<portNumber>/” is not allowed, then you can do a double redirect using the OAuth2.AppCallbackUrl property.  On your web server, setup an endpoint to receive the redirect and then respond to it with a redirect to “http://localhost:<portNumber>/”.    See the online Chilkat reference documentation for more information.