Exactly. Changing the OS is a long way off if people want to use these
technologies today.
I agree completely, nothing is going to change overnight. What I
would like to do is encourage all of us to look towards the future.
Eventually, we can have our cake and eat it too (have something with a
great UX *and* be secure).
That said, what I would like to push for is a updating the OAuth spec
(and Twitter's implementation) to support non-browser-based
authentication gateways, as I described in link [1].
As pointed out, this solution has one flaw, and that it is still
requires the provider to trust the owner of the authentication
gateway... which, until OS vendors provide a blessed gateway, would
be the apps themselves. OAuth purists wouldn't like this because it
requires trusting apps, but that point is moot given the embedded web
view workarounds so many apps are using (as pointed out in prior
posts, and in the linked discussion thread).
As I wrote on my blog, we can build a system today that leverages [an
updated version of] OAuth, has great UX and can be upgraded to
something perfectly secure once OS vendors get on board. Until then,
we'd have a system that is *just* as secure as Basic Authentication,
as it would require users to trust the clients (consumers) that they
use... (and if you use any email client today, well, you'd be a
hypocrite to complain).
Twitter folks helped *invent* OAuth, and it's a really clever/creative
solution. It would be awesome if they were the first to go live with
an even better implementation of it.
Loren
As far as the security issues, this is a problem that was discussed recently
on the OpenID User Experience list:
First message:
http://openid.net/pipermail/user-experience/2009-February/000298.html
Follow the thread:
http://openid.net/pipermail/user-experience/2009-February/thread.html
I can't say that we came to a satisfying conclusion.
However, one option could be to do the authentication bit in the app, and if
the user is concerned about using the built-in browser, offer a link to sign
in via the browser. Of course, if it's a nefarious app, they probably will
just not include that link, and without UI consistency where people know to
look for such a thing, that may be a moot option.
Therein lies the argument *against* popping the authentication to the
browser: if you're using a nefarious app and have launched it, you're
probably hosed already.
It's probably just a matter of time before some Jailbroken iPhone app for
Facebook proves this point, so we're at a cross-roads between user education
and usability.
I also see this more as a problem for e.g. the iPhone where you usually
need to close the application in order to jump to safari. This is not such a
problem on the desktop and (as you demonstrate) has been done for quite a
while with flickr.
Pownce actually did this, and I don't think that the experience was all that
bad:
https://wiki.oauth.net/OAuth-for-Pownce-on-iPhone
With using custom protocol handlers, you can make the experience quite
smooth actually. Confining the user to the task at hand is a bit harder, but
it's not impossible to handle the case where the user never completes
authentication.
I also agree with [2] that authenticating for multiple services might make
this whole process a bit annoying. We might also face this issue in the
proposed MMOX IETF working group[3] if we go with OAuth and in order to
connect to a world you might first need to authorize various services
(profile, inventory, contacts, IM, ...).
Yeah, this is why I advocate for strong identity, and an identity hub that
essentially talks to your federated services on your behalf, but is your
single point of authorizing third party apps to interact with your stuff.
I hope these visual examples help to demonstrate current practices in the
wild. I know that this kind of thing freaks us out:
http://www.flickr.com/photos/factoryjoe/3260710115/
...but it's clear that that's not the case for all developers.
Chris
--
Chris Messina
Citizen-Participant
Open Web Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is: [ ] bloggable [X] ask first [ ] private
