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.
2009/7/28 chinaski007 <chinaski...@gmail.com>
> 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
> 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
> 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
> (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.)