Re: [OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication

Hey Colin

You're right; this can be an interesting issue. It's very tied up in identity - if you are talking about connecting accounts (like you would with Facebook) then there's a layer missing from OAuth that provides the identity on top of it. At the moment, there are a few proposals (for instance, OpenID Connect) which distinguish between an immediate request (which returns immediately) vs a regular request (which does not). 

For now, I think the right behavior is for the client to give the user a chance to switch accounts. That means the identity layer needs to offer a way to log out as well as authorize ( see http://www.sociallipstick.com/?p=189 for more thoughts on this). If you are using Facebook, we offer a custom way to log the user out (http://developers.facebook.com/docs/reference/javascript/FB.logout ).

In any case, Facebook will likely add this layer on top of OAuth once it becomes a little more settled. There has been a lot of discussion on this list lately about exactly what form that should take.

Does that answer the question?

On Jun 24, 2010, at 9:07 PM, Colin Snover wrote:

> Hi everyone,
> 
> I apologise if this has been discussed previously; I searched the list 
> and did not see anything about it.
> 
> I have been working extensively with OAuth as a client author. A big 
> limitation that we are consistently running into with the way OAuth 
> currently works is that there is no way to tell the authorization server 
> that it needs to ask which end-user is requesting access.
> 
> In instances where an end-user may have more than one account on a 
> single provider, or where multiple end-users share the same computer, a 
> problem occurs when the provider assumes that the account currently 
> logged-in in the user-agent is the one that the end-user wants to 
> connect. This assumption, while useful in most cases, causes major 
> problems and a very frustrating user experience when the client has 
> previously been authorised for the logged-in account and the provider 
> immediately redirects back with an access token. In these cases, the 
> user has no ability to choose to authorize a different account unless 
> they manually log out of the provider’s site first or revoke 
> authorization from the provider’s site.
> 
> We need a way for the client to tell the authorization server “please do 
> not automatically assume that the account currently logged-in is the 
> account that we are requesting access for”. I would propose adding a new 
> optional query component to the end-user authorization endpoint, 
> force_auth. When this query component exists and is equal to 1, a 
> provider MUST ask for the user’s credentials before either automatically 
> redirecting back (if the client is already authorized) or presenting 
> them with the prompt for authorization.
> 
> Thank you for your time and consideration of this matter. I hope this 
> feature or something similar can make it into OAuth 2, since otherwise 
> we are going to have huge headaches and may end up needing to resort to 
> cross-site request forgery to force user-agents to log out of provider 
> sites. If I have been unclear at all, please let me know and I will be 
> happy to clarify.
> 
> Regards,
> 
> -- 
> Colin Snover
> http://zetafleet.com
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth