The OAuth Conundrum
Joshua Perry
Recently I went through and implemented OAuth and was excited to have it
working. I'm not sure exactly why I was excited, maybe it was the shiny
OAuth buzzword or the technical challenge of the implementation itself.
Either way I was trying to justify the problems with using OAuth for a
desktop application (storing the consumer secret in the app) while
defending the jagged auth workflow to my UX/Designer friend.
My friend sent me this blog post [1] (I believe the author is on this
list) and though I agree with it generally there is one sentence that
really stood out to me "it's a fantastic solution to _authenticate other
web apps_". After mulling this over I think that this sentence should
have been the author's final conclusion.
OAuth is all about delegating access to a third party without revealing
your credentials, which makes a lot of sense when there is a third
party. In the OAuth example; giving access to my photos stored on a
website a la Flikr to a company a la Shutterfly that prints photos where
I may want to limit the time and/or scope of the third parties access
without revealing credentials.
A similar OAuth use-case in the Twitter realm is Twitpic or Tipjoy where
the third party service needs to access my account to provide some
service, again, without revealing credentials and while reserving the
right to revoke that access granularly.
When using a desktop application there is no third party to reveal your
credentials to, the desktop application *IS* the user, where is the
delegation? As an example, think of an email client; nobody thinks
twice about putting their IMAP credentials into Thunderbird and there is
not really any security threat in doing so. If the user wants to revoke
access, they uninstall the application or simply stop using it.
I'll call these applications -- which could be applications on a
desktop, a blackberry, an iPhone, etc. -- "Proxy Apps" as they they do
not act as a delegate of the user, but as a proxy for the user.
So, as of this morning I have backed OAuth support out of our desktop
application and will continue to use basic auth from now until a
suitable replacement is developed (see next).
Now I'm not one to criticize without being constructive. I believe that
a credential-based authentication scheme should persist in the Twitter
API specifically for proxy applications, though I don't believe that
HTTP Basic Auth is that scheme.
If Twitter would make a form of Digest authentication available the
proxy apps would need to only store a hash of the user's credentials
locally. Storing only a hash of the user's credentials would eliminate
two of the largest issues with credential-based auth; storing plaintext
credentials, and sending plaintext credentials across the network.
Gavin Bell
On 26 Mar 2009, at 16:14, Joshua Perry wrote:
>
>
> My friend sent me this blog post [1] (I believe the author is on this
> list) and though I agree with it generally there is one sentence that
> really stood out to me "it's a fantastic solution to _authenticate
> other
> web apps_". After mulling this over I think that this sentence should
> have been the author's final conclusion.
>
Ideally Twitter would have implemented token based authentication from
the start as Flickr did, which would have avoided this whole migration
of authentication techniques.
However Twitter have said that OAuth is their preferred authentication
approach for the future, to roughly quote Doug from Tuesday night's
Twitter Devnest meeting. Given that I feel it is much more confusing
to have one means of authenticating desktop applications and another
for web applications.
For a good desktop OAuth like experience look at the MarsEdit and
Flickr integration.
It is all about the language used on the interfaces
From media panel click link to go to Flickr to authorise Marsedit's
access to Flickr (photos are on Flickr)
Authorise on flickr.com
Back to Marsedit, screen now says using an obvious button, "verify
access" (ie pick up previously requested token)
Click this link, Marsedit in the background gets the token and
refreshes the with your photos from Flickr.
More steps than entering an email address and password, I'll agree,
but this will be the common pattern across both web apps and desktop
apps.
OAuth is also permission based, rather than letting the third party
application act as if it were the person
It is clear what permission are being delegated and no surprises like
tweets being sent without your permission.
With a password based system this is not possible.
One authentication system in the future is definitely to be preferred
in my view to one for the desktop and one for the web.
For another example of how this can work look at Yahoo's Fire Eagle,
which uses OAuth for both desktop and web auth.
I'm not saying OAuth is a panacea, but it is better than handing over
a password.
thanks
Gavin
--
Gavin Bell
w - takeoneonion.org (weblog) and gavinbell.com
e - me at gavinbell dot com
zzgavin most places on the web
Cameron Kaiser
> > list) and though I agree with it generally there is one sentence that
> > really stood out to me "it's a fantastic solution to _authenticate
> > other
> > web apps_". After mulling this over I think that this sentence should
> > have been the author's final conclusion.
> Ideally Twitter would have implemented token based authentication from
> the start as Flickr did, which would have avoided this whole migration
> of authentication techniques.
>
> However Twitter have said that OAuth is their preferred authentication
> approach for the future, to roughly quote Doug from Tuesday night's
> Twitter Devnest meeting. Given that I feel it is much more confusing
> to have one means of authenticating desktop applications and another
> for web applications.
I think it's hard to say "ideally." Ideally *from a security perspective*,
sure, but it has been observed and said by many people, not merely yours
truly, that Twitter's API would probably not have the wide utilization it
does if they had insisted on a token based auth from the very beginning.
How many scripts are out there that are basically curl and a cron job? A lot.
Unless they can migrate turning off Basic Auth will shut them down, which
may or may not be a bad thing, but it was so easy to implement that they
became Twitter users. That does count for something.
This again should not be construed as a vote of no confidence in OAuth
because I'm converting TTYtter (a desktop app) to it too, and there are clear
advantages for certain functional domains. But I think it needs to be
pointed out that OAuth is not always *the* solution, nor always the best
solution in a field of inferior ones.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "I am Pentium of Borg. Division is futile. You will be approximated." ------
Ed Finkler
greatly to interesting, unexpected uses of the API, especially those
that involve automation. I absolutely feel that the availability of
OAuth is a Good Thing, and for many use cases it is practically
essential, but it is also unsuitable for some.
OAuth as the only authentication scheme will create a much higher
barrier for simple exploration of the API. That will be disappointing
to me if it happens.
--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funk...@gmail.com
atebits
> a password.
for iPhone apps), but the fact is it's only marginally better than
handing over a password. I mentioned this in my blog post (linked
above), but if I'm a native app, I can get your password if I want it
- OAuth or not. It's nothing more than the illusion of security in
this case.
To the twitter-folk: for implementation simplicity, I think you should
run with token-based authentication and deprecate Basic Auth. All I
ask in return is a "special" API method to exchange a username
+password for an access token. This way I can collect a username
+password client side (without directing the user to a webpage) and
authenticate. From the user's perspective, it's just as easy as
OAuth. From Twitter's perspective, all authentication will be routed
the same way*.
Loren
* And then... down the road (as I mentioned in the blog) OS vendors
can step up to the plate and provide a native, system-level interface
for OAuth++ authentication. It'll be better than both worlds: just as
simple for the user as Basic Auth, and even MORE secure than OAuth-
though-a-browser.
Joshua Perry
The big difference for a web application is the callback url and the fact that the webapp is already running in a browser directly. Those two facts mean that to the user the delegation process is one smooth flow.
The delegation process for a proxy application on the other hand is at least two context switches (from desktop app to web browser, back to desktop app when twitter tells you to) that do not exist in the web application delegation flow.
In a worse case type scenario imagine a proxy app on an iPhone; the iPhone only runs a single application concurrently. The user installs the application and clicks its icon on the home-page to launch it, the application promps the user to click a button to authorize the application, the browser comes up and the proxy app is Quit! The user then has to log in to Twitter using the mobile browser, click the Accept button, close the browser, find the original application on their home screen, and run it.
I don't know if you have had experience in directly supporting end-users but it is a flow like this that makes the system completely break down for the lay-person.
It's ugly, its unnecessary, and it is even described by the OAuth spec itself as undefined.
Gavin Bell
but is this not just a case of tool maturity though?
It is hard to beat cron and curl, but tools like
http://intridea.com/2009/3/23/twitter-auth-for-near-instant-twitter-apps
will make it easier to get past the auth setup and on to making an
interesting app.
OAuth is still pretty young compared to basic auth, the tools will get
better I think
I still think that OAuth as a single framework for web and desktop is
a desirable model to aim for.
Migrating the current Basic Auth acquired users to OAuth tokens will
be a challenge though.
registering your OAuthness with twitter.com or responding to a
particular API call could then start a token issuing process?
Joshua Perry
OS's do have a built in proxy authentication scheme, Windows calls it CardSpaces, everyone else calls it OpenID.
There is a standard credential -> access token transformation that Twitter could leverage. It's called Digest authentication and by the pure virtue of how a hash works there is no need for a negotiation of this token.
@Gavin: OAuth is better than handing out a password? Maybe better when working with a third party, but it adds absolutely no benefit when using a proxy application. Maybe you should stop using email until providers switch IMAP and POP to OAuth. What is the point of "delegating" access to an application on your own desktop/device? If I wanted to harvest Twitter credentials there are simpler ways than implementing a twitter client to do it; maybe a fake twitter client that asked for username/password even after basic auth is expunged, or maybe just another of the millions of spyware apps that log keyboard activity.
John Adams
On Mar 26, 2009, at 10:34 AM, atebits wrote:
>
>> I'm not saying OAuth is a panacea, but it is better than handing over
>> a password.
>
> That's the crux of it. It's not a panacea (the UX sucks, especially
> for iPhone apps), but the fact is it's only marginally better than
> handing over a password. I mentioned this in my blog post (linked
> above), but if I'm a native app, I can get your password if I want it
> - OAuth or not. It's nothing more than the illusion of security in
> this case.
It's not an illusion of security, it's a shift of control. In the
current system, the third party application has the user's credentials.
If the third party app goes rogue and performs malicious actions,
under OAuth, Twitter can revoke the application's rights wholesale, or
the user can revoke the application's rights to their account only.
> To the twitter-folk: for implementation simplicity, I think you should
> run with token-based authentication and deprecate Basic Auth. All I
> ask in return is a "special" API method to exchange a username
> +password for an access token. This way I can collect a username
> +password client side (without directing the user to a webpage) and
> authenticate.
Ah, but then your application would have the user's password.
The scheme you propose is a good intermediary step for a transition,
but not as a long term solution.
> From the user's perspective, it's just as easy as OAuth.
Although much harder to revoke!
-j
---
John Adams
Twitter Operations
j...@twitter.com
http://twitter.com/netik
Joshua Perry
run it. And like I said in my other message, you don't need to follow
the rules if you are trying to be evil, so the whole argument against
allowing proxy applications to exist just because one could go rogue is
a moot point.
Gavin Bell
understandable. It takes about 15 seconds.
I reset my auth and tried it again today, it is all down to the
language used to help people through the experience.
The MarsEdit experience is helped in that there is an immediate goal,
that of accessing a photo on Flickr.
The iPhone is a different case, I agree that is will lead to awkward
user experiences, I've done an OAuth dance on an iPhone and it is not
pretty. Though it does work with the various Fire Eagle apps on the
iPhone, so twitter developers are not the first to experience these
issues.
However I was talking about desktop apps in my earlier email. I
diagrammed the OAuth from desktop issues in 2007
http://www.flickr.com/photos/gavinbell/2086140377/
Take this to the OAuth IETF group
http://groups.google.com/group/oauth
They are aware of these issues
I'm not saying OAuth has solved all the problems, but it is better
than giving away your whole identity and a single auth framework means
it is more likely to become a solved problem
atebits
control to users and Twitter. I disagree with the details of the
implementation. (In particular using the browser as a crutch).
> Ah, but then your application would have the user's password.
much whatever I want.
> The scheme you propose is a good intermediary step for a transition,
> but not as a long term solution.
blessed OS-provided authentication gateway to replace the "browser" in
the OAuth equation. And there's no reason why it needs to be limited
to a GUI. A command-line authentication gateway would be possible
too.
> > From the user's perspective, it's just as easy as OAuth.
> Although much harder to revoke!
provided auth gateway thing...)
Loren
Ed Finkler
climb up when comparing HTTP Basic Auth to any alternatives.
Comparable toolsets for a wide range of languages and environments
won't be available for a long time, if ever.
In addition, my real concern, as stated above, is with apps and
scripts that do automated tasks. These kinds of things frequently
execute outside of a modern GUI desktop environment, and all the OAuth
workflows I've seen (including your example) have assumed that a
graphical web browser is a click away. That's simply not the case
with, say, the scripts that pull data down for my data mining
experiments.
I am afraid that going OAuth-only will effectively kill off these
kinds of apps. That would suck, in my opinion.
--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funk...@gmail.com
> Fair point, there do seem to be more twitter apps than say Flickr apps,
> but is this not just a case of tool maturity though?
>
Chad Etzel
attempting to move to OAuth in the near future. My plan is just to
create a "dummy" app under my main account and then write a simple
"Get Your Access Token" page on my website and use it for each of my
"bot" accounts to create and save access tokens to put in the scripts.
I am working with PHP scripts mostly, so using Abe's fantastic
TwitterOauth lib makes this rather simple, but I can see how things
like a cron job w/ curl or a bash script would be much more difficult.
Not sure if a perl lib has been created by anyone yet.
Anyone else dealing with the script/automation issue in a different manner?
-Chad
Steve Brunton
>
> Anyone else dealing with the script/automation issue in a different manner?
>
That's pretty much going to be my plan. Dummy "Script Automation of
Doom" Application and then just a basic webapp that auths and does
it's thing for that to get the token that then gets dumped into a
config file.
-steve
Joshua Perry
OAuth is for delegating access to a third party and is not the right tool for this job, and if everyone implements it then the Twitter developers will have more reason to remove Basic Auth and not provide a proper proxy authentication method.
Gavin Bell
the approach has been as you describe. Using token based auth means
the user needs to tell twitter that it is ok for your app to access
their content. This means there is a token waiting for your app.
On the web this is via the nice callback,
From the desktop you need to tell your app to go and fetch it. I
believe the MarsEdit example to be easier than checking your email for
a link to click on, something people do on a regular basis.
Command line scripts can check to see if it exists on their next
access for that user.
On the iPhone it is more of a dance, see the Fire Eagle apps for the
experience
http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice
The Pownce app did show that this is an issue
http://immike.net/blog/2008/09/08/oauth-on-the-iphone/
The pownce:// handler is a nice idea, saves hunting around for your
app again, have safari launch it for you.
There is a mailing list for OAuth in Objective C
http://groups.google.com/group/oauth-objective-c
Perl library has been around since 2007, http://nearlyfree.org/oauth-perl
OAuth has a wide range of language and framework support already
http://oauth.net/code
Steve Brunton
> 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
Joshua Perry
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.
Chad Etzel
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
Matt Sanford
TjL
> 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.
This low bar is what has allowed me ANY access to the Twitter API,
because low-bar shell scripts are what I can do. So I just wanted to
say "thanks" for not shutting us off hastily, and if you need folks to
talk to about "how high is too high to keep the low bar from getting
too high" then, well, I'm your guy :-)
- @T"I took a couple of courses in Pascal and decided I didn't want to
be a CS major, so I just diddle around with shell scripts"J
Paul Kinlan
Matt Sanford
Joshua Perry
have to speculate on some matters any longer.
I can tell by the lack of responses to my posts that people don't
totally agree with my feelings on the subject. I don't try to be
confrontational, I just tend to be very literal and a bone-headed
purist. Though, throughout the discussion I have tried to limit my
posts to facts and statements directly from the OAuth specification itself.
I've left the code for OAuth in our application so that it can be
reenabled with a simple compile switch. The overall flow was fairly
smooth, though not as simple as basic, and the couple of tickets that
are open on the topic are deal breakers for us right now. We'll present
it to our users for their consideration once the Twitter OAuth
implementation has matured a bit.
Josh
Shannon Whitley
I'm happy with the the solution for my web apps. Having said that, I
don't think it should be "the" way to authenticate. Basic Auth has
been so easy to implement that I think it has fostered very creative
solutions from people who just wanted to "try" a few ideas. I know
I've thrown quite a few things together for fun (e.g. Twitter in
Excel). The creativity that simple authentication spawns is
important, and I agree with the others who have expressed that on this
thread.
MPS
I'm working on an iPhone app that uses the Twitter API.
This is a side project for me with a small budget and tight timelines.
I'm using Matt Gemmel's Objective-C library to integrate with Twitter.
Everything was going along smoothly, until I realized that in order to
get Twitter to acknowledge my app (i.e. tweets from my app say "from
web" rather than "from [my app]"), I need to use OAuth.
(Older apps are being "grandfathered" in. How nice for them.)
Matt's library doesn't support OAuth, and attempts by others to patch
it have been less than successful.
From my perspective, the requirement to use OAuth has added days of
overhead to my project (blowing my estimates) and negatively impacted
the user experience.
For what it's worth, I agree completely with Josh; OAuth isn't adding
value to anyone in this scenario. But it seems I've arrived too late
to this party. :-(
- Michael
Zachary West
>
> I thought I'd add my $.02 to this thread.
>
> I'm working on an iPhone app that uses the Twitter API.
>
> This is a side project for me with a small budget and tight timelines.
>
> I'm using Matt Gemmel's Objective-C library to integrate with Twitter.
>
> Everything was going along smoothly, until I realized that in order to
> get Twitter to acknowledge my app (i.e. tweets from my app say "from
> web" rather than "from [my app]"), I need to use OAuth.
>
> (Older apps are being "grandfathered" in. How nice for them.)
>
> Matt's library doesn't support OAuth, and attempts by others to patch
> it have been less than successful.
Feel free to check out the modifications I made for Adium:
http://hg.adium.im/adium/file/tip/Plugins/Twitter%20Plugin/MGTwitterEngine
This uses OAuth Consumer.framework and works pretty well. I don't know
how well it translates over to the iPhone (the OAuth consumer part),
but the OAuth details are ridiculously easy.
Beware though, if you venture out of that folder you're going to have
to GPL (that's where the OAuth token exchange, etc, happens. The
example code on the OAuth website should help though).
>
> From my perspective, the requirement to use OAuth has added days of
> overhead to my project (blowing my estimates) and negatively impacted
> the user experience.
I found I was able to do it in a few hours, really.
>
> For what it's worth, I agree completely with Josh; OAuth isn't adding
> value to anyone in this scenario. But it seems I've arrived too late
> to this party. :-(
>
> - Michael
@zacwest
Michael Pelz-Sherman
I was planning on spending those hours doing other stuff, but that's not such a huge deal. :-)
I am still concerned about how OAuth will affect the user experience of my app.
The main issue is that the OAuth authorization web page doesn't display well on the iphone.
Is there a mobile-friendly version of that page?
- Michael
From: Zachary West <zac...@gmail.com>
To: twitter-deve...@googlegroups.com
Sent: Wednesday, May 6, 2009 6:11:46 PM
Subject: [twitter-dev] Re: The OAuth Conundrum
Chad Etzel
http://code.google.com/p/twitter-api/issues/detail?id=395
Click the star by it to up the vote.
-Chad