> 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
