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,
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
