This just goes to show how badly suited OAuth is for desktop applications: Basically, what ever you do, you will need to direct your users over to a browser (or embed one) and they'll have to deal with strange "passcodes" or whatever you want to call it.
This is much more difficult for a user to understand ("why can I give twitter my password, but in this client here, I have to do this strange dance? What am I supposed to do now?").
In most of the client apps, the issue of having to enter your password is a non-issue as there's no need for a third-party to know it.
In the case of desktop apps, IMHO, OAuth does nothing but makes the lives of both client developers and users harder.
After setting up Twitter which uses OAuth 1.0, try Facebook's OAuth 2.0 - it's amazingly easy in comparison since it doesn't use secrets, simply relying on HTTPS's SSL encryption instead.
Thanks Jeff, this is exactly what I've been looking for. I found out about twitter killing basic auth today, but all the documentation seems to assume you have a web app. I just run a simple RSS scraper to twitter feed script on a cron job, so this is helpful.
Once I have generated an ACCESS_KEY and ACCESS_SECRET, when will they expire? Is there any way to programmatically grant/approve OAuth access so that expired access key and access secret can be generated as needed?
I wonder how difficult it would be to implement xAuth. Presumably, the configuration for username/password could be left intact because xAuth is performed by giving the username/password.
This is much more difficult for a user to understand ("why can I give twitter my password, but in this client here, I have to do this strange dance? What am I supposed to do now?").
In most of the client apps, the issue of having to enter your password is a non-issue as there's no need for a third-party to know it.
In the case of desktop apps, IMHO, OAuth does nothing but makes the lives of both client developers and users harder.