Re: [OAUTH-WG] ' force_auth' request parameter

["William Mills" <[e-mail]>]

I agree with the below.  
 
To be clear, the case where we had a problem with this is a 3 legged flow, where we as the 3rd party direct a user through an auth flow to be redir3ected back to us.  In this case it's nto the browser specifying, it's the partner/integrator with a service.


________________________________

	From: Colin Snover [mailto:[e-mail]] 
	Sent: Tuesday, July 13, 2010 11:21 AM
	To: Eran Hammer-Lahav
	Cc: William Mills; David Recordon; OAuth WG; [e-mail]
	Subject: Re: [OAUTH-WG] ' force_auth' request parameter
	
	
	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" <[e-mail]> 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-mail]] 
				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 <[e-mail]>  wrote:
				
				 
				 
				

					
					 
					I think it's a mistake not to have force_auth in the  core.
					
					 
					

					
					 
					
________________________________

					From: David Recordon  [mailto:[e-mail]] 
					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  <[e-mail] <mailto:[e-mail]> >  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: [e-mail] <mailto:[e-mail]>   [mailto:[e-mail] <mailto:[e-mail]> ]  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 <[e-mail] <mailto:[e-mail]> >
		Date:  Sat, 10 Jul 2010 11:01:11 -0700
		To: Eran  Hammer-Lahav <[e-mail] <mailto:[e-mail]> >
		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/[e-mail]/msg02331.html> <http://www.mail-archive.com/[e-mail]/msg02331.html> 
					
					Regards,
					



	-- 
	Colin Snover