login flow: three options

[Michiel de Jong]

Hi!

For the demo I'm currently using what i call the two-step flow:

- browse to a web app

- put in your username (but not your password yet)

- get a popup of your unhosted storage provider

- put in your password

- redirected back to the app, popup closes.

- logged in.

But there are two alternative flows that i can think of though, so i wanted to collect opinions on this:

nascar flow (after the cacaphony of many colourful logos usually found on nascar racing cars) :

- browse to a web app

- find the icon of your unhosted storage provider, or type its domain name into 'other' (experience with OpenId shows this can be confusing for an end user)

- get a popup of your unhosted storage provider

- put in your username and password (note that you don't need webfinger here)

- redirected back to the app, popup closes.

- logged in.

client-pwd flow:

- browse to a web app

- put in your username and password (note the app sees your password, even if it doesn't need to store it)

- get a popup of your unhosted storage node asking what to give access to (even if you already gave the master password, so a bit silly there, unless you have one password per resource, but that defies the advantages of oauth a little bit)

- redirected back to the app, popup closes.

- logged in.

maybe there are more alternatives that i haven't thought of?

Cheers!

Michiel

[@eschnou]

For the demo I'm currently using what i call the two-step flow:

- browse to a web app

- put in your username (but not your password yet)

- get a popup of your unhosted storage provider

- put in your password

- redirected back to the app, popup closes.

- logged in.

This is my prefered one, keep in mind that you may already be logged in your storage provider (so you won't have to enter your username again), but you may want to 'authorize' the app to use your data (and put some restrictions like read-only). In fact, this is similar to a twitter or facebook oauth flow, and something that user are getting used to. I would try to match these user experience since they are what users expect nowadays.

I wonder if you could leverage something like XAuth to make it even simple and skip the step where you have to enter your username.

http://xauth.org

Cheers,

Laurent

[Michiel de Jong]

i would say XAuth without WebFinger is not good enough, but XAuth definitely adds something that WebFinger doesn't provide, so yes! :)

ref. Video about XAuth: http://vimeo.com/12121710

Although we would have to think about how to define 'services' for that. In the beginning of the video, it's strictly about the "Like"/"Share" service. Later on it's about the "please state your name and business" service. in our case it could be about the 'unhosted dav storage' service, and there you already start needing more room for specifying details about what service you actually mean, as is also mentioned at the end.

I saw an interesting statement on the XAuth list, that really the only service you would want to advertise through XAuth would be WebFinger. That is, use XAuth minimally on top of WebFinger, to basically add a 'remember me' cookie to a web app before even your first-time visit to that web app. After your first use, the web app could do this itself, so the Stack Overflow example mentioned in the XAuth video is not entirely relevant imho: XAuth is only relevant from providers you have set to 'remember me' in the current browser, to retrievers you have never logged into before. But yes, let's add XAuth on top of WebFinger! It'll be a relevant improvement of the user experience.

Thanks a lot for the pointer!

Cheers

Michiel

[Blaine Cook]

XAuth is horrible. Please don't use XAuth.

It's basically Facebook's privacy-hating cookie bullshit, but writ large and without any privacy.

To put it more clearly: if you use XAuth, *any* website you browse to will know that you use unhosted. This immediately opens up unhosted users to further attacks.

To wit: Imagine the hypothetical xploitauth.org, implemented by the CIA or the porn industry, which shares (using the same mechanism as XAuth) which sites you've visited.

As far as I'm concerned, XAuth is a bug in the browser security model. I'm not sure there's a fix, but privacy-respecting folks MUST NOT use XAuth.

Okay, that said, here's how it should work. imnsho. ;-)

User enters email address (login), webfinger lookup happens, login follows. If the webfinger lookup fails, fallback to username / password or email confirmation is possible. The reason you have to ask for the user's name (i.e., can't do it automatically) is because if the user wants to login with a different identity, they need to be able to choose which identity to present.

Basically the goal is to allow the user to enter a memorable login, and not have the usability catastrophe that is NASCAR (which doesn't work except for the three most globally recognised login brands – Twitter, Facebook, and sometimes Google).

b.

[@eschnou]

XAuth is horrible. Please don't use XAuth.

Oops :-) 

Ok, if Blaine says so, trust him, don't use XAuth ! 

@blaine great to see you are watching this space :-)

Cheers,

- Laurent

[Michiel de Jong]

On Fri, Mar 25, 2011 at 2:22 PM, @eschnou <laurent.e...@gmail.com> wrote:

XAuth is horrible. Please don't use XAuth.

Oops :-) 

Ok, if Blaine says so, trust him, don't use XAuth ! 

OK :) The argument of information leaking is convincing, thanks for warning.

 

@blaine great to see you are watching this space :-)

I couldn't agree more, of course. And I say the same to you, Laurent! You guys are really helping a lot with all these decisions, and it's important that we get all of them right. :)

Cheers!

Michiel