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>
*Date: *Sat, 10 Jul 2010 11:01:11 -0700
*To: *Eran Hammer-Lahav <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>
*
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>
tools.ietf.org/html/draft-ietf-oauth-v2-09
<http://r6.sharedcopy.com/6bnqq8v> · Original page
<http://tools.ietf.org/html/draft-ietf-oauth-v2-09>
------------------------------------------------------------------------
via sharedcopy.com <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>
Regards,
--
Colin Snover
http://zetafleet.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
