The problem I see with pushing this up into an identity layer is that
providers that choose to implement their own identity layer (or no
identity layer) may still end up doing this implicit authorization
thing. We’re neither providing a specific identity to connect nor are we
requesting identity information from the provider—we simply want to make
sure that the provider is not re-using any previous authorizations (a
session cookie is just an authorization key by another name), because
doing so leads to the scenarios I’ve written about (and probably others
that I have not considered).
Under an authorization system that did not require the use of a Web
browser, I would agree much more strongly with the notion that this
should be part of a separate layer, but the problem is that the spec
*does* utilize Web browsers heavily, and so we need to make
considerations for the spec keeping that in mind.
To address Eran’s concern about overstepping bounds, perhaps the
language could be changed from MUST to SHOULD, which would leave it up
to the provider to make the ultimate decision whilst still being in
compliance with the spec? I certainly don’t want to step on any toes in
that regard, but I also don’t want providers to think they can ignore
this just because it’s a little easier to do so.
Regards,
On 13/07/2010 11:57, David Recordon wrote:
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
<http://mail...@sharedcopy.com>>
*Date: *Sat, 10 Jul 2010 11:01:11 -0700
*To: *Eran Hammer-Lahav <e...@hueniverse.com
<http://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://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>
<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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Colin Snover
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
