The trick is to create a hybrid auth process. You register a web app at a domain you own, authorize users for a web app via the OAuth for Web Apps process, then implement a mechanism by which their installed app can pick up that authorization from the web app.
My thinking on this would be that the installed app would send your site a request for a keypair. It would receive an initiate key and an authorize key, both of which you'd store in a database at the web site for one time use.
The app would then use whatever mechanism to launch an external browser, pointing it to
yourdomain.com/authorizestart.php?initiate=[initiate code]. The site stores the code in a session variable, then sends the user off to Google to authenticate. When authentication is successful and Google sends the user back with the next token, you store it in the database entry related to the initiate key.
The user closes the browser, clicks a "done" button in your app, and the app then sends a request to yourdomain.com/tokenretrieve.php?authorize=[authorize key]
Your site looks up the Google token and transmits it back, the app completes the Oauth process.
The issue with this is that you have to share the "consumer secret" you created in the registration process with the app. Someone could decompile it or try to capture its output and discover your secret key which is part of the method for encrypting responses from the Google servers. That said, how is that worse than using "anonymous" as your consumer secret?