I'm sorry, but I don't know how you can call this a common interface
between web apps and proxy apps. The only similarity is that they are
pushing a big green Accept button in both flows.
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 wrote:
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
