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
