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

[Colin Snover <[e-mail]>]

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