[twitter-dev] Re: The OAuth Conundrum

[Paul Kinlan]

Hi matt,

I generally like the idea and implementation of oauth and the general  
flow.

My main issue is for the vast amount of sites such as twe2 and twollo  
that key their accounts off twitter and use twitter as an  
authentication mechanism now have to introduce a new login mechanism  
and account managment, which for established sites is not easy to do.

We have an oauth login implementation on http://oauth.twe2.com that  
uses the twitter oauth process nearly every time a user needs to login  
to our site. I think it works well but is not what oauth is for.

I have seen suggestions of using rpxnow, and whilst it is excellent it  
just adds so much confusion when we have to redirect a twitter user to  
facebook or google to log in to a twitter app.

Those are my issues that most people seem to think are nonplus.

Just for information I have seen just 20 requests for oauth on twe2  
which is 0.1% of our active userbase (if I have my figures right).

Thanks,
Paul

On 27 Mar 2009, at 20:04, Matt Sanford <m...@twitter.com> wrote:

Hello there,

    It seems there have been a few threads lately that end in  
frustration about Basic Auth going away. Going into the OAuth beta  
we were thinking that we would ideally [1] turn off Basic Auth in  
the future. Based on the feedback (that's what betas are for,  
right?) we've seen some usages that don't fit the OAuth model and  
we're working out what we can do to go on supporting those.  
Supporting those may mean some addition to OAuth [2] or keeping  
Basic Auth around in some form [3]. We're still in beta and we have  
not set a date when Basic Auth will be removed, nor do we know if it  
ever will. That's what we're trying to figure out during this beta.  
All of this feedback is helpful but sometimes it borders on FUD
 I read all of the mails on the list but I don't have time to reply  
to each one. Let's all say it together: Don't Panic.

    The low barrier to entry with the Twitter API it a great feature  
we don't want to lose. We think about it often, and I think about it  
all of the time in relation to OAuth. I see this as a concern as  
much as cron jobs and TwitPic integration. Possibly more so since  
all of those things are bourn of that ease of use. We don't want to  
lose that ease of use and we're working to find a way to keep that  
and increase user security.

    I don't have all of the answers. I suggest people who fit the  
OAuth flow (webapps, etc) implement it, those that are close  
(desktop apps) try it, and those that are totally outside of it hang  
tight. We need some desktop and mobile apps to try it so we can find  
out what works. Everybody knows it's hard, but if you've used  
desktop apps with the Flickr API you know it can be done pretty  
smoothly.

Thanks;
  — — Matt Sanford / @mzsanford

[1] - Ideally (adv.) - preferably; in a perfect world
[2] - http://groups.google.com/group/oauth/browse_thread/thread/bdf8b99e84a8aaef
[3] - We're not sure what form. Maybe HTTPS only, using all of the  
feedback on this list to figure it out.

On Mar 27, 2009, at 10:58 AM, Chad Etzel wrote:


It seems to me that Twitter themselves have said (or at least heavily
implied) that Basic Auth will GO AWAY in the future.  Therefore,  
OAuth
will be the ONLY hammer to use when driving nails.

Now, if that stance has changed and Basic Auth will be available
forever more, then I am more than happy not to waste my time building
OAuth into all of my scripts (I really have better things to do), and
Mr. @funkatron will win the day.  So far there has been no indication
of this, so I am preparing (as well as other devs) for the  
forthcoming
(unannounced as of yet) flag day when The Basic Auth In The Sky Mad
Scientist Switch Gate is flipped off by Al3x and Matt wearing lab
coats and big goggles while laughing maniacally with Jacob's Ladders
sparking madly behind them (I want video of this).

It's not because we *want* to, it's because we *have* to.

I'm going to trump Dossy here and give his requisite "love the bomb"
speech, blah blah blah... done.

Now, let's look at it from another perspective really quick.  It  
could
be the case that Twitter decides to leave Basic Auth on forever along
side OAuth.  It may be that in the twitter app ecosystem (web or
desktop/iphone), that apps that use Basic Auth will be shunned by
users and ultimately fail b/c everyone is so ga-ga over OAuth finally
being the "solution" for Twitter user security/protection (it's not
really, but the illusion is all people want to believe).  Thus, apps
that want to survive may be forced by peer-pressure to implement  
OAuth
to gain user adoption.

The opposite may happen, as has been suggested, that since Basic Auth
is so easy for both devs and users alike, that it may still reign
supreme as the preferred authentication method, and instead the OAuth
apps will be shunned for being too user unfriendly.

Who knows what would really happen?  It might be a fun experiment to
find out, but it's ultimately up to Twitter.  Right now the plan laid
out before us is "OAuth or Nothing", so that's what we're all  
planning
for.

-Chad

On Fri, Mar 27, 2009 at 1:31 PM, Joshua Perry <j...@6bit.com> wrote:
Thats exactly what I am saying, just because OAuth is the hammer  
that the
Twitter developers are providing to solve the third party  
delegation problem
doesn't make every problem a "nail", and I don't understand why  
everyone is
jumping on board trying to shoehorn OAuth into every  
authentication scheme.

If we as users of the API don't want to subject the users of our
applications, or ourselves when writing personal scripts, to OAuth
machinations for no reason then we should let the Twitter  
developers know.
Just blindly jumping on the bandwagon is going to give them the  
impression
that everything is great.

Use OAuth where it was meant and designed to be used, in the realm  
of third
party delegation and revocation, and leave it there.

Steve Brunton wrote:

On Fri, Mar 27, 2009 at 12:33 PM, Joshua Perry <j...@6bit.com>  
wrote:


Seriously guys, whats the point in implementing OAuth for stuff  
like this?
Why do you need to "delegate" access rights to your scripts, your  
scripts
_are_ you, acting as a proxy to the Twitter API as you.



If Basic Auth is going to go away at some point in time; well, then
we'll have to have this to actually authenticate and authorize the
scripts unless some other means becomes available. If Basic Auth is
never ever ever ever ever going to go away then you are correct we
don't need to worry about doing such delegation to our scripts. I
posed the same question earlier and never saw a response or a
suggestion that there might be an alternate plan in the works for
those of us that do backend internal work of such things, so I'm
currently planning the OAuth route.

-steve