OAuth-like user experience examples

[Chris Messina]

I uploaded two sets of screenshots today demonstrating an OAuth-like flow on the desktop and on the iPhone:

iPhone: Flickit to Flickr

http://wiki.oauth.net/Flickit-to-Flickr

Desktop: iPhoto to Flickr

http://wiki.oauth.net/Flickit-to-Flickr

Would be happy to have a discussion about these current examples, especially in light of some of the recent feedback from Twitter devs [1][2].

Chris

[1] http://blog.atebits.com/2009/02/fixing-oauth/

[2] https://twitter.pbwiki.com/oauth-desktop-discussion

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

[Jesse Stay]

How would a user verify against Phishing on a device like the iPhone if the apps are controlling the direct to the authenticating website?

Jesse

[Abraham Williams]

Here is the iPhoto to Flickr link:

http://wiki.oauth.net/iPhoto-to-Flickr

--
Abraham Williams | http://the.hackerconundrum.com
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.

[Chris Messina]

On Sat, Feb 21, 2009 at 6:55 AM, Christian Scholz / Tao Takashi (SL) <tao.t...@googlemail.com> wrote:

I guess you wanted to link to http://wiki.oauth.net/iPhoto-to-Flickr

Whoops, thanks!

 

Would be happy to have a discussion about these current examples, especially in light of some of the recent feedback from Twitter devs [1][2].

So I am wondering in the iPhone case how I can be sure that I am really at yahoo and not somewhere else. I don't see any URL, whether it's SSL or not etc. and even if I would this application could of course fake this as well (which I guess is also the point in [1]). So I agree with [1] that a better way would be something inside the OS to provide that but that this of course also might not happen (or at least soon).

Exactly. Changing the OS is a long way off if people want to use these technologies today.

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

[atebits]

> 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