Twitter, OAuth and bti

So Twitter finally dropped Basic authentication, and now OAuth (twitter's implementation though) is the only way to authorize clients.

I'm not going to tell you how bright is the idea behind OAuth, the idea of letting an application to do things on behalf of you without letting it know your credentials, the idea of revoking the access of misbehaving application as soon as it started being fishy, the idea of letting the server to revoke the consumer's access whenever it wants, cause of course you all know these. But wasn't that application (the one service provider decided to revoke access), the one you authorized earlier on? You and hundreds of thousands of other users? Apparently it doesn't matter, after all you are not the ultimate resource owner.

The shiny new twitter client (which you may have even paid for, and/or even better you got it from a distribution channel) stopped working? Who's to blame? Depends on whom you ask. Twitter would eventually blame developers for not being able to hide their key and secret.

But is it really developer's underdo? OAuth specifications clearly state that the service provider shouldn't solely rely on the secret as a method to verify the consumer identity, because it's pretty damn easy to extract the key, and secret if the client is a desktop application, ergo the answer is "No".

Enough rant, time to talk about the third part of the post's title.

"bti" is an open source CLI twitter/identi.ca client originally developed by the famous hacker Greg Kroah-Hartman to annoy the whole world by piping the bash input as tweet/dent. I sent my first patch (readline support) in February 2009, and after that I couldn't resist sending more patches (e.g., read support) because Greg is a pleasure to work with, he accepted all my silly patches, and silently fixed all the issues with them.

When a bug filed at debian BTS for sending bti to grave for not having OAuth supprot, I thought it's about time to make bti OAuth aware. The obvious was to register bti, and put the consumer key, and secret in the source. Wait, what?! You Idiot! Twitter has warned that would kill all OAuth keys seen in the wild - yeah, that's what you do when you solely rely on the secret (I know, I switched off the rant earlier, but the rant was inevitable). So we decided we'd better not distribute the key and secret, thus there's no key bundled with bti.

OK, this is what you should do in order to allow bti to tweet (thanks to Greg, the Basic auth support is still there, since Identi.ca has OAuth service provider too, I was tempted to purge Basic auth's codebase entirely):

• Go to http://twitter.com/apps/new to register a new application. Set the "Application type" as "Client", and "Default Access type" to "Read & Write".


• Open bti config file (~/.bti), and put these two lines into it:
  
  consumer_key=THE_CONSUMER_KEY_IN_APPLICATION_DETAILS_PAGE
  
  consumer_secret=THE_CONSUMER_SECRET_IN_APPLICATION_DETAILS_PAGE
  
  


• Run bti, if things go well bti should print an URL, open that in your browser, and allow bti to access your account. Copy the PIN and paste it in bti prompt. Now bti should print access_token_key, and access_token_secret, paste those two lines in your bti config file as well.

That's it!