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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
