My PowerBuilder app is attempting to connect to Quickbooks Online using your OAuth1 example. I cannot use localhost as a callback because I can't depend on the localhost:port being possible for the callback. I'd like to use our web server at mycompany.com for the callback. Is this possible?
First, it's good to understand the details of the OAuth2 flow to see why using localhost might not be the problem you're thinking it may be.
Here's what generally happens in OAuth2 (assuming your app is requesting authorization to access some user's Quickbooks account that you don't own).
1) Your app (using Chilkat in this case) sends a POST to Quickbooks to get a request token, from which you'll construct a URL to be loaded into a browser. You'll also start a background thread to listen on a port for the eventual callback.
2) Your app starts a browser window and loads the URL from step1. This is where your app's user will interactively authorize your app to access his/her Quickbooks data in some way (perhaps read-only).
3) The user will click on an "Allow" or "Deny" button, and this causes the browser to send a POST to the callback URL. The background thread receives the HTTP POST (from the browser running on the same machine). Thus, when you use "localhost" for the callback, the communications to localhost is coming from the same local machine because it's the browser that's sending the POST. Therefore, you probably don't need to worry about firewalls blocking the POST because it's not an incoming HTTP POST from "out there". You may, of course, have trouble with your pre-specified port if the particular computer is using that port for something else. You can pick a port where your odds are one in thousands that it'll be an issue -- which may still be unacceptable for some.
If you instead decide to use a callback URL that is on your company's web server, then the final POST from the browser is sent to your web server, where you'll need to have an endpoint that is capable of receiving the POST and getting the query parameters. Of course, that this point you'd have your desktop app running on the user's local machine that does not yet have the actual access token. Your server-side code on your company's web server has the access token. So you'd have to invent a means for your app to send a request to your web server to get the access token that it previously received from the browser. For example, maybe after the user clicks "Accept" in the browser, he would then click on some sort of "Fetch Access Token" button in your app that would send a request to your web server where you've squirreled away the access token in some way.. :)
In summary, here are the tasks you'll face if using a non-localhost callback URL. (They're really not so bad..)