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> 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] *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> > *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><http://www.mail-archive.com/oauth@ietf.org/msg02331.html> > > Regards, > > -- > Colin Snoverhttp://zetafleet.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
