OAuth is also a huge pain for those "I just want to write a little Twitter API script in 5 minutes" things. To the extent that I've thought about writing a couple lately, but chose not to because I didn't want to deal with OAuth (and they were scripts I'd want to work in the future).

It seems like there should be some solution that lets me use basic auth for those little scripts. Maybe tell Twitter IP's from which I want to be able to use basic auth? It would be a bit of a pain since most people have dynamic IP's, but it would be better than nothing, and it would at least make it simple to run basic auth scripts on my VPS (which obviously has a static IP).

One pain point I've had since switching from Basic Auth has the lack of debugging via a terminal and curl. That was pretty useful.

For Ruby-minded folks there's http://github.com/marcel/twurl which is effectively curl that uses OAuth - though it isn't the same.

John Nunemaker wrote a tutorial on how to get get up and running with OAuth pretty quickly (though it is for the Ruby/Rails audience) http://railstips.org/blog/archives/2009/03/29/oauth-explaine... .

I'll admit getting started with OAuth takes some time to ramp up at first, but that ramp up time gets smaller each subsequent app.

It really couldn't be much easier with the twitter gem, and it's way easier to clean up after an "oh shit I left credentials in that public script" moment; just re-generate the secrets on the twitter site.

https://gist.github.com/cfc477a0c5895e8bd1bd

Wrote this when I was drunk to prove a point.

I wrote http://github.com/decklin/curlicue for precisely this reason. It's kind of a hack (shell script!), but I've gotten some mileage out of it.

An opt-in, per user, enable of basic auth might be a nice thing, but probably a hassle for them to implement.

I made a fun little app for this: http://simpleauthtwitter.heroku.com/ it's not very complicated, but it might help.

For a single-user use case you could use http://dev.twitter.com/pages/oauth_single_token which doesn't require you to go through the OAuth token acquisition dance.

There's an oauth curl to write script quickly with oauth and curl http://code.google.com/p/oacurl/

Twitter's OAuth is a total pain to implement.

If they had just upgraded to OAuth 2.0 like Facebook recently launched, I'd be happy.

Facebook's OAuth can be done in like 10-20 lines of code. Twitter's takes like 100 (in PHP+Curl).

(essentially OAuth 2.0 just relies on https SSL instead of directly encrypting tokens via code before they are sent)

Yes, the most painful part is having to copy the pin number manually for non web apps, a real pain. I read twitter is working on the oauth 2.0 spec themselves with facebook and google, so we may get some relief soon.

I haven't worked with OAuth 2.0 yet, but I've been meaning to take a look at it with Facebook's update.

However in Ruby/Rails OAuth isn't that bad using http://twitter.rubyforge.org/ . And aside from a couple hiccups, I haven't had any problems with http://code.google.com/p/oauthconsumer/wiki/UsingOAuthConsum... on iPhone/iPad (I'm using the Browser redirect and re-launching the application from a custom application protocol).

I assume xAuth was put in place for the apps that the user really only accesses directly when they need to change something - things like RSS -> Twitter reposters. In this case an app may not be able to get in touch with a user to inform them they need to authenticate using OAuth. However this could be solved by having the developer email their users to tell them they need to re-authenticate.

Is there an actual reason to use xAuth over OAuth aside from having to put users through the trouble of re-authenticating? You have to have special permission from Twitter to use xAuth but who knows how easily they hand it out.

From what I've gathered, if OAuth is the only authentication mechanism and you can't easily redirect a user to a browser and back then xAuth is your best option. Though I suppose you could so something funky like emailing a user a link and have them return back with the PIN (for the Out-of-Band workflow).

Reading the API mailing list it sounds like Twitter is granting xAuth access on a 1-2 week timeline. Though that may be based on the size of the email queues.

This makes me quite annoyed as well. Whenever I've asked Twitter about it, they simply say "The applications still use an OAuth access token to access the API, so it's still a secure authentication option." That's not the problem. The application may have to use the access token to use the API, but there's absolutely nothing stopping them from storing the password in their databases behind the scenes.

I'll grant you that xAuth is a little convoluted. With that said, Twitter deserves credit for being unprecedentedly accommodating and transparent during the transition away from basic auth. It is obviously in their best interest not to break applications, but this hasn't stopped other social networks cough from yanking the rug from underneath scores of apps with little to no warning.

danhak, you make a good point. And I should have probably specifically mentioned that. Twitter Support has really been going the extra mile to help developers make the migration.

I wrote a simple script to post an RSS feed that my university uses to twitter. (Actually, I hacked up Stammy's It currently has about 190 followers, but it used Basic Auth so it stopped working on Thursday.

Rather than switching to OAuth, I'm tempted to just write a mechanize script to make posts using the web interface. Has anybody tried this approach?

You could just use http://twitterfeed.com. Unless of course your script modifies the RSS data significantly before posting it.

I have made exactly the same thing! But now I guess I'll either read their documentation or use one of the scripts/libs listed above.

I've written such a script to hit the website directly. That "API" is far flakier than the basic auth version.

Its not just password security. A big part of oath is to control the API better. Twitter can now shut down misbehaving apps/sites by revoking their key.

Sure, you might just be able to create a new user and key if you get banned but this still gives them one more tool and a better picture of who is sending what over their network.

Even easier, malicious apps can simply use another client app's key. OAuth wasn't really designed for desktop client authentication. The revocation you propose is predicated on the app key being a secret, but desktop clients can't keep secrets.

See the section in the relevant RFC:

http://tools.ietf.org/html/rfc5849#section-4.6

Could it be that Twitter is going the route of Apple? This raises the barrier to entry just enough to keep out developers who are just goofing around.

Otherwise, no, I don't see it. I know that I'm less inclined to write a little hack to work with Twitter without basic auth.

Seems like this author just doesn't realize how painful migrating to OAuth is for a service provider. Of course xAuth isn't a real security improvement to HTTP Basic. But it forces everyone to support auth that isn't inherently broken. So once Twitter stops receiving many xAuth requests, they can just turn it off.

The migration to OAuth 2 will be interesting though. All the existing clients will have the right kind of structure to plug in drop in a replacement flow, but I bet there will still be a bunch of complaints. "OMG I don't want to use HTTPS! This is so hard! Who cares that I can use curl to debug now, I want programming to be drag and drop." Haters gonna hate.

joseph, you have a good point about how large of a task migrating all service providers from Basic to OAuth is. And I have to give Twitter Support credit for their work helping developers along the migration.

But your argument still doesn't explain why Twitter's supported service still uses xAuth. Or Twitterrific (and they have a significant market share). What is blocking them from migrating from Basic to non-xAuth OAuth?

>"I just want to write a little Twitter API script in 5 minutes"

In that case you would use Out-of-band/PIN Code Authentication. See http://dev.twitter.com/pages/auth_overview.

For Pythonistas, my little Twitter API script uses tweepy.py. Thanks to http://jmillerinc.com/2010/05/31/twitter-from-the-command-li... for the steps involved. As an exercise, you could scrape the required PIN with beautifulSoup or similar code to eliminate one step.

I don't see what the big deal is. It took me a few hours to update Factor's Twitter library for OAuth -- and that included writing the OAuth support library. The whole thing is only a couple of hundred lines of code.

I've created 2 small web apps that made use of Twitter and authenticated via oauth. It's been pretty simple for the most part. Since I develop in rails, I've had the pleasure of using twitter-auth for authentication.

Generally speaking though, this is a great move by Twitter in my opinion. I'm always a bit concerned when a 3rd party website asks for a username and password. In some cases I no longer provide credentials when I know a certain service provides oauth.

It might not be as easy for non-web based applications, but I'm sure things will improve in the long run.

I have a non-web, non-desktop based twitter app with a couple thousand users and just haven't had the time available to figure out how to get it doing newAuth.

xAuth seems like it'd work, but, as stated in the article, that involves me going through some hoops to get back to this level of security. woo.

For Java or Jython I use htmlunit in Facebook to simulate a browser in the login process, the same can be applied to twitter.