I agree with the below.
To be clear, the case where we had a problem with this is a 3 legged flow,
where we as the 3rd party direct a user through an auth flow to be redir3ected
back to us. In this case it's nto the browser specifying, it's the
partner/integrator with a service.
________________________________
From: Colin Snover [mailto:ietf....@zetafleet.com]
Sent: Tuesday, July 13, 2010 11:21 AM
To: Eran Hammer-Lahav
Cc: William Mills; David Recordon; OAuth WG; jh...@photobucket.com
Subject: Re: [OAUTH-WG] ' force_auth' request parameter
The only other thing I could think of to suggest would be to change the
spec to state that an authorization server MUST NOT rely on Cookie or
Authorization headers from the user-agent during the end-user redirect phase as
being safe for use in authentication.
To me, at least, it seems obvious an authorization server should
*never* think user-agent authorization tokens (e.g. session cookies, basic
auth) are a safe way of authenticating incoming authorization requests. Doing
so puts too much trust in the user-agent and allows the client to bypass the
first phase of authentication when it can't really do so securely. This is only
a problem because OAuth *requires* use of a Web browser during its
authorization flow. Unfortunately, lots and lots of providers are already doing
this, and the only way I can think of to make it stop it is to make it verboten
in the spec, even if it causes the spec to deviate slightly into the
authentication arena in this one particular area.
As far as (very legitimate) concerns regarding inconsistent user
experience go, let's look at how the current OAuth system works in practice. No
matter what, *any* authorization action taken by an end-user in a client can
potentially mean either "log in and then authorize", "authorize", or "do
nothing while we automatically refresh the client with a new token and redirect
you back". That's already a *huge* disparity in what happens *within the same
client*, and it's painfully bad.
I think Justin Hart got it exactly right when he said there should be
four options. Even if what happens is not always the same, clients can manage
user expectations *much* better than providers by providing cues about what
will happen *before* auth flow starts. With the current way it works, basically
all the client can tell the user is "we have no idea what will happen once you
click this button except maybe your account will get connected to our site if
you do it exactly right; good luck!".
Regards,
On 13/07/2010 12:28, Eran Hammer-Lahav wrote:
User authentication and approval interaction has always been
the sole domain of the authorization server. This proposal shifts the decision
towards the client. It is unclear to me why is the client better suited to make
this decision? In the context of identity, if a client relies on the server for
its own identity services (e.g. Facebook connect), it makes sense for the
client to request stronger authentication than just cookies. But outside the
identity context, I am unconvinced the client is likely to make a smart
decision. In addition, if we let the client specify this, it will mean
different client will have different user experience on the same server which
is confusing and odd.
I'm not opposed to this, just that I don't think this is well
thought out.
EHL
On 7/13/10 10:18 AM, "William Mills" <wmi...@yahoo-inc.com>
wrote:
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:e...@hueniverse.com]
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
<wmi...@yahoo-inc.com> wrote:
I think it's a mistake not to have
force_auth in the core.
________________________________
From: David Recordon
[mailto:record...@gmail.com]
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 <wmi...@yahoo-inc.com <mailto:wmi...@yahoo-inc.com> > 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: oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org> ] 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 <mail...@sharedcopy.com
<mailto:mail...@sharedcopy.com> >
Date: Sat, 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <e...@hueniverse.com
<mailto:e...@hueniverse.com> >
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> >
tools.ietf.org/html/draft-ietf-oauth-v2-09
<http://tools.ietf.org/html/draft-ietf-oauth-v2-09>
<http://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 sharedcopy.com <http://sharedcopy.com>
<http://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/oauth@ietf.org/msg02331.html>
<http://www.mail-archive.com/oauth@ietf.org/msg02331.html>
Regards,
--
Colin Snover
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
