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

[Colin Snover <[e-mail]>]

  Hi,

I just wanted to follow up and see if I could solicit a bit more 
feedback on this request, since it sounds like the end of the OAuth 2 
spec is growing near and I would like to see something added to resolve 
this problem if at all feasible (or suggestions on how else to deal with 
it; maybe OIDC is the solution but it’s only half a solution if it’s 
optional/supplementary).

Thanks,


-- original message follows --

On 25/06/2010 02:30, Colin Snover wrote:
> On 24/06/2010 23:30, Luke Shepard wrote:
>> 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?
>
> Hi Luke,
>
> Thanks for writing. I’m obviously flying a little blind in regards to 
> what’s already been proposed, so I appreciate the links.
>
> I took a brief look at OpenID Connect. If I am reading this correctly, 
> it would resolve our issue since the client would collect and pass the 
> desired user_id to the authorization server, right? I guess the 
> biggest problem I see here is that unless OIDC support is mandated in 
> the OAuth spec, implicit authorisation will probably continue to 
> happen with providers that don’t want to support it—and I’m guessing 
> there would be a fair amount of opposition to any sort of strong 
> coupling between OAuth and OIDC?
>
> I also did a little more digging through the mailing list while 
> investigating what you said and saw that there was a suggestion 
> earlier for an “immediate” parameter, which appears to address the 
> opposite of the situation I’ve raised and was added in draft 2 (but 
> removed in draft 7). Notes on draft 7 don’t seem to mention its 
> removal, so I’m not entirely sure why it is gone now (because it would 
> mean that OAuth would need to become an identity layer?), but it 
> sounds like there is a desire for /three/ different modes of OAuth 
> operation: an “immediate” mode, a “default” or “hybrid” mode (like 
> OAuth 1.0a), and an “always-reauthenticate” mode. Is that accurate?
>
> Unless I’m misinterpreting what is being suggested, I don’t think that 
> an option to provide a “Log out” link to end-users from within clients 
> is the right way to solve this problem. The ability to authorise 
> multiple accounts from one provider at the same time is essential to 
> what we are trying to do; switching only makes sense if the client can 
> only handle one account at a time. Beyond that, there are a few other 
> issues I can think of with this proposal, which I hope have been 
> raised before:
>
> 1. Logging a user-agent out of a provider’s site isn’t really what we 
> want to do here; we just want to provide the end-user an opportunity 
> to authorise an account that happens to /not/ be the account their 
> user-agent is already logged into. Maybe the provider decides that 
> this needs to cause a log out, but OAuth ideally shouldn’t /require/ 
> the interruption of another existing session just because we happen to 
> be using the same user-agent for authorisation.
>
> 2. If a programmatic method for logging out was required to solve this 
> problem, it would be wide open to abuse by people that want to be 
> annoying and force people to get logged out of their providers’ sites. 
> (This isn’t terribly uncommon, of course, since most log-outs are 
> simple GET requests, but it seems like something that would be good to 
> avoid perpetuating. I don’t know how Facebook deals with this.)
>
> 3. It also seems like a fairly bad idea from a privacy standpoint to 
> provide a mechanism that allows an unauthorised client to determine 
> whether or not a visitor is already logged in on a particular 
> provider’s site, since it opens up a new avenue for history sniffing, 
> etc. In order to resolve the issue I have raised through the use of a 
> “log out” button in the client, this would seem to be necessary 
> without compromising look-and-feel through the use of an iframe. (I 
> seem to have inadvertently neglected to mention in my original message 
> what happens when an end-user’s UA is already logged in to a provider, 
> but the client is /not/ yet authorised: if they want to pick a 
> different account to authorise instead of the already logged-in 
> account, they have to log out of the provider, optionally log in with 
> the correct credentials, then go back to the client and restart the 
> OAuth request from the beginning. That sucks too!)
>
> Anyway, TL;DR: Being able to pre-provide information as to which 
> account is being requested, à la OpenID Connect, is one potential 
> solution, but unless it’s mandated along with OAuth 2, the implicit 
> authorisation problem will still exist for providers that opt out of 
> OIDC. Without turning OAuth into an identity layer, it would seem that 
> a flag to force reauthentication à la my original proposal would be 
> necessary. Of course, this would not solve the “immediate” problem, 
> but it sounds like that’s not safely solvable without identity anyway. 
> Maybe there is another option, but I’m not able to think of one.
>
> Regards,
>


-- 
Colin Snover
http://zetafleet.com