On twollo.com I have not seen any issues yet with the changes - no one has ever complained about the "Sign in with Twitter" option. But I am very glad that Twitter implemented OAuth, I don't have to manage the credentials in the same way - Authenticate using Twitter has been a god send for me, and I am glad I harped on about it for as long as I did, the UX is pretty smooth. >From a usage point of view, twollo has about 15000 oauthed users, this is about 30% of the user base..... I still provide the option to authenticate using your password (I might remove this soon) - I honestly can't tell why people want to keep giving me their usernames and passwords but they do.
If you check http://www.friendboo.com, because I had already implemented Twitter OAuth it was really simple to implement FriendFeeds OAuth - purely because the process is very similar across services - I imagine that this is the case for other services too. I honestly wish Twitter would get out of the oAuth is not meant for production use mindset and really start making people use oAuth. Paul 2009/7/28 chinaski007 <[email protected]> > > > Let's be honest... > > The end-result for third-party developers using OAuth appears to be > fewer sign-ups, less reliability, more complexity, and potentially > less security. > > Google Optimizer reveals that users are more likely to sign-up for > Basic Auth than OAuth. That's just fact. Test it for yourself to > confirm. > > I suppose this is not so weird. Users are accustomed to giving user/ > pass information even to "foreign" apps. It is far more disruptive > and invasive for them to go to some bizarre Twitter screen asking them > to "approve an app". To the average user, what does that mean? (And, > heck, it may even require more steps if they have to login again to > Twitter.) > > In terms of reliability, Twitter OAuth was down for days several weeks > ago. Tonight yet another unannounced change occurred that broke major > code libraries. Meanwhile, Basic Auth has been plugging along just > fine and dandy... > > So what IS the benefit of OAuth? > > It doesn't benefit developers as you will likely get more sign-ups > with Basic Auth and Basic Auth is far, far easier to setup. Sure, > OAuth might satisfy some power users hungry for security... > > But is OAuth even more secure than Basic Auth? > > Perhaps not. After all, tonight's fix was for an OAuth security flaw > known for at least 10+ days (judging by tweets to @twitterapi) that > allowed for potential impersonations of credentialed users. > > On the heels of Twitter's (unofficial) assurance of better > communication with developers, this sort of unannounced change is > distressing. What's next? (Have Labor Day Weekend plans? You might > want to cancel those... just the right time for Twitter to make an > unannounced API change!) > > As for us, we are in the strange position of deprecating OAuth in > favor of Basic Auth. > > Weird, eh?? > > Okay, we are not totally deprecating OAuth, but we are advising users > that Basic Auth is far more robust and reliable. > > And so our message to new developers: avoid OAuth like the plague. If > you must, offer it. But let Basic Auth be your backbone: more > reliable, more sign-ups, simpler, and probably just as secure. (Just > look at Google Code bug reports about OAuth to get a sense of > reliablity.) > > (Okay, okay, this post was written at 4am after a workday that started > at 8am, and after Twitter introduced this new change at 5pm... (hey > Twitter, can you introduce major new changes EARLIER in the day so we > can react!?!?)... it still doesn't excuse Twitter's continued > disregard for the small-to-medium size developer.) > >
