I agree it changes the boundaries. I think this one needs moving. As I said
we hit a significant problem with this, which we solved by virtue of the fact
that the target we were working with has an un-crumbed logout, so we could XSRF
the logout.
It's something people get wrong and we should make a way to get it right.
________________________________
From: Eran Hammer-Lahav [mailto:[email protected]]
Sent: Tuesday, July 13, 2010 10:08 AM
To: William Mills
Cc: David Recordon; Colin Snover; OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth' request parameter
The question is if we have consensus to force providers to support it.
It seems to overstep the boundaries we set over the years and it makes
assumptions about how services authenticate users and obtain approvals.
EHL
On Jul 13, 2010, at 13:05, William Mills <[email protected]> wrote:
I think it's a mistake not to have force_auth in the core.
________________________________
From: David Recordon [mailto:[email protected]]
Sent: Tuesday, July 13, 2010 9:58 AM
To: William Mills
Cc: Colin Snover; Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth' request parameter
I support immediate and a form of forced auth (ala
OpenID's PAPE) but not in the core spec. They both should be part of an
identity extension.
On Tue, Jul 13, 2010 at 9:51 AM, William Mills <
<mailto:[email protected]> [email protected]> wrote:
I agree with Colin that some form of force_auth
is needed. I haven't read enough on the "immediate" proposal, but I know that
we have run into the problem of trusting currently set cookies in the browser
(even when we're actually sending a username/password and really do want to
have an authentication).
I'm a +1 on the force_auth proposal.
________________________________
From: <mailto:[email protected]>
[email protected] [mailto: <mailto:[email protected]>
[email protected]] On Behalf Of Colin Snover
Sent: Tuesday, July 13, 2010 9:23 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth'
request parameter
On 22/07/28164 13:59, Eran Hammer-Lahav
wrote:
The following was submitted via the
shared-copy page but does not belong with editorial feedback. This needs to be
discussed and supported on the list before added the specification. I think it
belongs where 'immediate' is specified.
EHL
------ Forwarded Message
From: An anonymous reader <
<http://[email protected]> [email protected]>
Date: Sat, 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <
<http://[email protected]> [email protected]>
Subject: Re: draft-ietf-oauth-v2-09 -
The OAuth 2.0 Protocol
"Colin Snover" left these comments on
your copy:
draft-ietf-oauth-v2-09 - The OAuth 2.0
Protocol < <http://r6.sharedcopy.com/6bnqq8v> http://r6.sharedcopy.com/6bnqq8v>
As proposed on the ML, a new
parameter to counteract the current behaviour of OAuth 1.0a authorization
servers which is to assume that the account logged into the user-agent is the
account that should be checked for access:
force_auth
OPTIONAL. The parameter value
must be set to "true" or "false".
If set to "true", the
authorization server MUST prompt the end-user to authenticate and approve
access. The authorization server MUST NOT make any assumptions as to the
identity of the entity requesting access, even if another automatic mechanism
is available to do so (e.g. browser cookies).
If set to "false" or not
present, the authorization server MAY automatically grant access to the client
if it is able to determine that access was previously granted. link » <
<http://r6.sharedcopy.com/6bnqq8v#shcp21>
http://r6.sharedcopy.com/6bnqq8v#shcp21>
<http://tools.ietf.org/html/draft-ietf-oauth-v2-09>
tools.ietf.org/html/draft-ietf-oauth-v2-09 < <http://r6.sharedcopy.com/6bnqq8v>
http://r6.sharedcopy.com/6bnqq8v> · Original page <
<http://tools.ietf.org/html/draft-ietf-oauth-v2-09>
http://tools.ietf.org/html/draft-ietf-oauth-v2-09>
________________________________
via <http://sharedcopy.com>
sharedcopy.com < <http://sharedcopy.com/?ef> http://sharedcopy.com/?ef>
------ End of Forwarded Message
Hi Eran,
Sorry if that was not the right place
for that to go; I didn't know what else to do. I have tried to solicit feedback
from the ML regarding this parameter twice and nobody seems very keen in
providing any, which is kind of a bummer. I waited until the last possible
moment to add it in the hopes that someone would notice my messages and discuss
it, but you made it sound like your plan was for draft 10 to be potentially
final so I wanted to get it in before the deadline.
I'm sure this is not a big deal for
most applications that expect at most a single connection, but for me this is a
huge deal since it completely immolates our application's authentication flow,
and I can't go to every provider asking them to please change the way they
implement the authentication portion of their OAuth API.
In contrast to 'immediate', which had
some concerns vis à vis security, force_auth is actually safer than the current
normal flow used by most OAuth providers since it requires the provider to make
no guesses about who is trying to authorize the app.
Frankly, I think that OAuth providers
do the wrong thing now in all cases by assuming that browser cookies are a safe
way of confirming the identity of the end-user making an authorization request
(they aren't!), but the spec says the way the authorization server
authenticates the end-user is outside the scope of the spec. I have no
objection to this-OAuth *should* be authentication-agnostic-but at the same
time this is a very real and present implementation flaw and the only way to
solve it is to make sure the spec defines a way for an application to say "hey,
I know you *think* you know who should be authenticated, but *I* know that the
user has requested to connect a *new* account, so don't use any automatic
authentication method".
I think it is incredibly important that
the OAuth spec gets providers to distinguish between automatic & potentially
unsafe authentication methods (like session cookies) versus more "guaranteed"
authentication (like password), especially since 99.999% of the time OAuth
relies on the end-user's Web browser which is all but guaranteed to contain
some cookies for the provider that are unrelated to the requesting application.
Examples:
1. Multiple end-users with malicious
intent. User 1 is logged into their Facetweetr account. User 2 wants to do bad
things using User 1's account. Because the user-agent has cookies for user 1,
user 2 gets to authorize their account with our app. Even when user 1 changes
their password, unless the provider automatically invalidates their existing
connections (the spec does not even mention doing this in an informative manner
as far as I can tell), they are almost certainly unaware that the linked
application is still able to perform actions on their behalf.
2. Single end-user with multiple
accounts. User is logged into Facetweetr account 1, but they want to authorize
account 2. They go to authorize the application and are presented with a
confirmation for account 1. They log out (because this is the only way to
switch accounts on the provider) and suddenly the authorization flow is dropped
on the floor. The user may not know immediately what they need to do at this
point. They will need to manually return to the original application and
restart the authorization request.
3. User has two accounts that they want
to authorize with a provider. User authorizes account 1 successfully, then
wants to authorize account 2. Because account 1 is still logged in, and because
the application already has a link to the account, it automatically redirects
back to the application's redirection URI. In order for the user to get what
they want, they are forced to manually navigate to the provider's site, log
out, *then* begin the authorization request.
These aren't imaginary scenarios; they
are things that are going on *right now* with several different OAuth providers.
The original request: <
<http://www.mail-archive.com/[email protected]/msg02331.html>
http://www.mail-archive.com/[email protected]/msg02331.html>
Regards,
--
Colin Snover
<http://zetafleet.com>
http://zetafleet.com
_______________________________________________
OAuth mailing list
<mailto:[email protected]> [email protected]
<https://www.ietf.org/mailman/listinfo/oauth>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
