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

From: Colin Snover <[email-masked]>
Date: Thu, 24 Jun 2010 23:07:24 -0500

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

---

From: Luke Shepard <[email-masked]>
Date: Thu, 24 Jun 2010 21:30:01 -0700

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:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Colin Snover <[email-masked]>
Date: Fri, 25 Jun 2010 02:30:10 -0500

> 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