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 <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
> 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.)
>
>

Reply via email to