At the end of Au­gust twit­ter de­cid­ed to drop Ba­sic Authen­ti­ca­tion for ac­cess to their API. This means an ap­pli­ca­tion can no longer con­nect to their sys­tem us­ing only a user­name and pass­word com­bi­na­tion be­long­ing to an ac­count. While this might make sense for the big ser­vices out there re­ly­ing on a con­nec­tion with twit­ter, for the two things I do with it it doesn't.

I can do what­ev­er I want with my twit­ter ac­count us­ing a web brows­er. I can log in us­ing my user­name and pass­word and that works as ex­pect­ed. But if you want to have the same func­tion­al­i­ty as a brows­er, but use the API, that brows­er sud­den­ly needs more than the user­name and pass­word to get the same data from the sys­tem. This makes sense if that brows­er is op­er­at­ed by a third par­ty and you don't want to give your pass­word to that third par­ty. The OAuth sys­tem pass­es a valid lo­gin into twit­ter for that ap­pli­ca­tion on to that ap­pli­ca­tion with­out telling it your pass­word. This makes cer­tain­ly sense if the third par­ty is a web­site.

But I'm mere­ly run­ning some lo­cal cron­jobs ac­cess­ing my twit­ter ac­count. To keep them func­tion­ing I need­ed to reg­is­ter them as an ap­pli­ca­tion with twit­ter so I get a con­sumerkey and con­sumer­secret for the OAuth au­then­ti­ca­tion. Us­ing that I can then treat my­self as a third par­ty and gen­er­ate to­kens that al­low my cron­jobs to ac­cess my ac­count with­out know­ing my pass­word. No prob­lems there.

But since the cron­jobs are just Perl scripts I might like to share, there is no point in­clud­ing the con­sumer­secret in those scripts. Be­cause if the se­cret is out there any­one can use that to pre­tend to be my reg­is­tered ap­pli­ca­tion, which is of course some­thing we don't want. So I put the con­sumer to­ken pair in my con­fig­u­ra­tion, and any­one who wants to use the same script will have to reg­is­ter their own ap­pli­ca­tion and can use their own con­sumer to­kens in their own con­fig­u­ra­tion.

This ap­proach of hav­ing every­one use their own reg­is­tered ap­pli­ca­tion's con­sumerkey and con­sumer­secret makes it ba­si­cal­ly an in­con­ve­nient way of us­ing a user­name and pass­word.

So why is twit­ter do­ing this? My guess is that this ex­tra lay­er of au­then­ti­ca­tion gives them a kill switch for every reg­is­tered ap­pli­ca­tion. With only a user­name and pass­word they can't pre­vent peo­ple ac­cess­ing the API with­out block­ing them also from the site. Us­ing the to­kens of a reg­is­tered ap­pli­ca­tion they can ex­pire the to­kens of an ap­pli­ca­tion to pre­vent that ap­pli­ca­tion from ac­cess­ing the API, but users can still use their own user­name and pass­word in their brows­er or oth­er ap­pli­ca­tions us­ing the API. And this makes it a busi­ness mod­el: If your ap­pli­ca­tion is gen­er­at­ing a lot of traf­fic, twit­ter will no­tice that by the num­ber of au­then­ti­ca­tions it's han­dling for that reg­is­tered ap­pli­ca­tion, and if you don't pay up your to­kens could be pulled or get a lim­it­ed rate. Un­less you teach your users to reg­is­ter their own ap­pli­ca­tion and use their own con­sumerkey and con­sumer­secret to ac­cess their own data.