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

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 11 Jul 2010 11:41:37 -0700

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 <[email-masked]>
Date: Sat, 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <[email-masked]>
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

---

From: Colin Snover <[email-masked]>
Date: Tue, 13 Jul 2010 11:22:42 -0500

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 <[email-masked]>
>     *Date: *Sat, 10 Jul 2010 11:01:11 -0700
>     *To: *Eran Hammer-Lahav <[email-masked]>
>     *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
>              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>
>
>
>     ------------------------------------------------------------------------

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/[email-masked]/msg02331.html>

Regards,

-- 
Colin Snover
http://zetafleet.com

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 09:31:20 -0700

Building consensus around new ideas is tough. The only advice I can give you is to identify the people most likely to support this idea and ping them off-list to try and get their support. I don't think it belongs in core because core currently represents pretty solid consensus on the feature set (and most details).

EHL

On 7/13/10 9:22 AM, "Colin Snover" <[email-masked]> wrote:

 On 22/07/28164 13:59, Eran Hammer-Lahav wrote:
' force_auth' request parameter 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

 force_auth

 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/[email-masked]/msg02331.html>

 Regards,

---

From: "William Mills" <[email-masked]>
Date: Tue, 13 Jul 2010 09:51:51 -0700

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: [email-masked] [mailto:[email-masked]] 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

		
		EHL
		
		------ Forwarded Message

		

			
			force_auth

			

		

	Hi Eran,

	

	
	Examples:

	

	The original request: <http://www.mail-archive.com/[email-masked]/msg02331.html> <http://www.mail-archive.com/[email-masked]/msg02331.html> 
	
	Regards,
	
	-- 
	Colin Snover
	http://zetafleet.com

---

From: David Recordon <[email-masked]>
Date: Tue, 13 Jul 2010 09:57:37 -0700

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 <[email-masked]> 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).
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *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
>
> 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
>
> *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
>          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>
>
>
> ------------------------------
> Sorry if that was not the right place for that to go; I didn’t know what
> 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”.
>
> 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:
>
> 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/[email-masked]/msg02331.html><http://www.mail-archive.com/[email-masked]/msg02331.html>
>
> Regards,
>
> --
> Colin Snoverhttp://zetafleet.com
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Justin Hart <[email-masked]>
Date: Tue, 13 Jul 2010 10:01:08 -0700

+1, though I would like to see it to be a little more specific.  Essentially there are four states.  'accept' (allow all cookies and consent as present in browser - for example how Facebook currently works), 'consent' (accept login, but still prompt for the allow/deny consent - for example, how twitter currently works), 'login' (don't accept login, but bypass the allow/deny consent), 'force' (don't accept login or consent).  The 'login' state could probably be dropped and 'force' used instead.
----
-- Justin Hart
-- [email-masked]<mailto:[email-masked]>

On Jul 13, 2010, at 10:51 AM, William Mills wrote:

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 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 <[email-masked]<x-msg://65/[email-masked]>>
Date: Sat, 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <[email-masked]<x-msg://65/[email-masked]>>
Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol

force_auth

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>

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.

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/[email-masked]/msg02331.html><http://www.mail-archive.com/[email-masked]/msg02331.html>

Regards,

--
Colin Snover
http://zetafleet.com<http://zetafleet.com/>

<ATT00001..txt>

---

From: "William Mills" <[email-masked]>
Date: Tue, 13 Jul 2010 10:02:20 -0700

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

	From: David Recordon [mailto:[email-masked]] 
	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. 

		 

				
				EHL
				
				------ Forwarded Message

				

					
					force_auth

					

				

			Hi Eran,

			

			
			Examples:

			

			
			Regards,
			
			-- 
			Colin Snover
			http://zetafleet.com

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 10:08:20 -0700

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 <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 13, 2010 at 9:51 AM, William Mills <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> 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).

________________________________
From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [mailto:<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>] 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

EHL

------ Forwarded Message
From: An anonymous reader <<http://[email-masked]>[email-masked]<mailto:[email-masked]>>
Date: Sat, 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <<http://[email-masked]>[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol

draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol <<http://r6.sharedcopy.com/6bnqq8v>http://r6.sharedcopy.com/6bnqq8v>

force_auth

         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>

<http://tools.ietf.org/html/draft-ietf-oauth-v2-09>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 <http://sharedcopy.com> sharedcopy.com<http://sharedcopy.com> <<http://sharedcopy.com/?ef>http://sharedcopy.com/?ef>

Hi Eran,

Examples:

The original request: <<http://www.mail-archive.com/[email-masked]/msg02331.html>http://www.mail-archive.com/[email-masked]/msg02331.html>

Regards,

--
Colin Snover
<http://zetafleet.com>http://zetafleet.com

_______________________________________________
OAuth mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

---

From: "William Mills" <[email-masked]>
Date: Tue, 13 Jul 2010 10:18:29 -0700

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:[email-masked]] 
	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

	EHL

	On Jul 13, 2010, at 13:05, William Mills <[email-masked]> wrote:

			On Tue, Jul 13, 2010 at 9:51 AM, William Mills < <mailto:[email-masked]> [email-masked]> wrote:

					From: <mailto:[email-masked]> [email-masked] [mailto: <mailto:[email-masked]> [email-masked]] 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

					
					EHL
					
					------ Forwarded Message

					From: An anonymous reader < <http://[email-masked]> [email-masked]>
					Date: Sat, 10 Jul 2010 11:01:11 -0700
					To: Eran Hammer-Lahav < <http://[email-masked]> [email-masked]>
					Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol

					 
					draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol < <http://r6.sharedcopy.com/6bnqq8v> http://r6.sharedcopy.com/6bnqq8v> 

					force_auth

					         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> 

					<http://tools.ietf.org/html/draft-ietf-oauth-v2-09> 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 <http://sharedcopy.com> sharedcopy.com < <http://sharedcopy.com/?ef> http://sharedcopy.com/?ef>  

					Hi Eran,

					

					
					Examples:

					

					The original request: < <http://www.mail-archive.com/[email-masked]/msg02331.html> http://www.mail-archive.com/[email-masked]/msg02331.html>
					
					Regards,
					
					-- 
					Colin Snover
					<http://zetafleet.com> http://zetafleet.com

				_______________________________________________
				OAuth mailing list
				<mailto:[email-masked]> [email-masked]
				<https://www.ietf.org/mailman/listinfo/oauth> https://www.ietf.org/mailman/listinfo/oauth

---

From: Colin Snover <[email-masked]>
Date: Tue, 13 Jul 2010 12:24:02 -0500

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 <[email-masked] 
> <mailto:[email-masked]>> 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).
>         *From:* [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Colin Snover
>>         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 <[email-masked]
>>             <http://[email-masked]>>
>>             *To: *Eran Hammer-Lahav <[email-masked]
>>             <http://[email-masked]>>
>>                  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
>>                      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 »
>>             via sharedcopy.com <http://sharedcopy.com>
>>             <http://sharedcopy.com/?ef>
>>
>>
>         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
>         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
>         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
>         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
>         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,
>         These aren’t imaginary scenarios; they are things that are
>         going on *right now* with several different OAuth providers.
>
>         The original request:
>     [email-masked] <mailto:[email-masked]>

-- 
Colin Snover

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 10:28:08 -0700

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" <[email-masked]> wrote:

EHL

On Tue, Jul 13, 2010 at 9:51 AM, William Mills  <[email-masked] <mailto:[email-masked]> >  wrote:

________________________________
From: [email-masked] <mailto:[email-masked]>   [mailto:[email-masked] <mailto:[email-masked]> ]  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

EHL

------ Forwarded  Message

From: An anonymous reader <[email-masked] <mailto:[email-masked]> >
Date:  Sat, 10 Jul 2010 11:01:11 -0700
To: Eran  Hammer-Lahav <[email-masked] <mailto:[email-masked]> >
Subject:  Re: draft-ietf-oauth-v2-09 - The OAuth 2.0  Protocol

draft-ietf-oauth-v2-09 - The OAuth 2.0  Protocol <http://r6.sharedcopy.com/6bnqq8v <http://r6.sharedcopy.com/6bnqq8v> >

force_auth

         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> >

Hi Eran,

Examples:

Regards,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 10:29:37 -0700

On 7/13/10 10:24 AM, "Colin Snover" <[email-masked]> wrote:

> 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.

A SHOULD directive works better with an extension than core. Inclusion in
core means it is, well, core...

EHL
 
>>> 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).
>>>  
>>>  
>>>  
>>>>> list before added the specification. I think it belongs where Oimmediate¹
>>>>> is specified.
>>>>>  
>>>>>  EHL
>>>>>  
>>>>>  ------ Forwarded Message
>>>>>   
>>>>>> From: An anonymous reader <[email-masked]
>>>>>> <http://[email-masked]> >
>>>>>>  To: Eran Hammer-Lahav <[email-masked] <http://[email-masked]>
>>>>>> >
>>>>>> account logged into the user-agent is the account that should be checked
>>>>>> for access:
>>>>>>  
>>>>>>  force_auth
>>>>>> 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).
>>>>>>  
>>>>>> access was previously granted.         link »
>>>>>>  via sharedcopy.com <http://sharedcopy.com>  <http://sharedcopy.com/?ef>
>>>>>>  
>>>>>>  
>>>>>  
>>>>  Sorry if that was not the right place for that to go; I didn¹t know what
>>>>  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
>>>>  In contrast to Oimmediate¹, which had some concerns vis à vis security,
>>>> OAuth providers since it requires the provider to make no guesses about who
>>>> is trying to authorize the app.
>>>>  
>>>> 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².
>>>>  
>>>> (like session cookies) versus more ³guaranteed² authentication (like
>>>> end-user¹s Web browser which is all but guaranteed to contain some cookies
>>>> Facetweetr account. User 2 wants to do bad things using User 1¹s account.
>>>> 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

---

From: "William Mills" <[email-masked]>
Date: Tue, 13 Jul 2010 10:34:34 -0700

I can live with SHOULD. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Eran Hammer-Lahav
> Sent: Tuesday, July 13, 2010 10:30 AM
> To: Colin Snover; David Recordon
> Cc: OAuth WG
> >     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 
> > doing so leads to the scenarios I¹ve written about (and 
> probably others that I have not considered).
> >  
> >  To address Eran¹s concern about overstepping bounds, perhaps the 
> > 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.
> 
> A SHOULD directive works better with an extension than core. 
> Inclusion in core means it is, well, core...
> 
> EHL
>  
> >  Regards,
> >  
> >  
> >>> 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).
> >>>  
> >>>  
> >>>  
> >>>>> belongs where Oimmediate¹ is specified.
> >>>>>  
> >>>>>  EHL
> >>>>>  
> >>>>>  ------ Forwarded Message
> >>>>>   
> >>>>>> 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 
> >>>>  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 
> >>>>  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 Oimmediate¹, 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².
> >>>>  
> >>>> 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.
> >>>>  
> >>>> 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.
> >>>>  
> >>>> 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,
> >>>>  These aren¹t imaginary scenarios; they are things that 
> are going 
> >>>> on *right

---

From: Colin Snover <[email-masked]>
Date: Tue, 13 Jul 2010 13:21:23 -0500

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 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.
>
>         *From:* Eran Hammer-Lahav  [mailto:[email-masked]]
>         *Sent:* Tuesday, July 13, 2010 10:08  AM
>         *To:* William Mills
>         *Cc:* David Recordon; Colin Snover;  OAuth WG
>         It seems to overstep the boundaries we set over the years and
>         it makes  assumptions about how services authenticate users
>         and obtain  approvals.
>
>
>
>         EHL
>
>
>
>
>                 *From:* David Recordon  [mailto:[email-masked]]
>                 *Sent:* Tuesday, July 13, 2010 9:58  AM
>                 *To:* William Mills
>                 *Cc:* Colin Snover; Eran  Hammer-Lahav; OAuth WG
>                 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
>                 <[email-masked] <mailto:[email-masked]> >
>                  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).
>
>
>
>                         <mailto:[email-masked]> ] *On Behalf
>                         Of *Colin Snover
>                             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
> <mailto:[email-masked]> >
> <mailto:[email-masked]> >
> <http://r6.sharedcopy.com/6bnqq8v <http://r6.sharedcopy.com/6bnqq8v> >
> *
>
>  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
> 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> >
>
>
> <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> >
>
>
>                         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
>                         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
>                         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:

-- 
Colin Snover

---

From: "William Mills" <[email-masked]>
Date: Tue, 13 Jul 2010 17:05:20 -0700

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:[email-masked]] 
	Sent: Tuesday, July 13, 2010 11:21 AM
	To: Eran Hammer-Lahav
	Cc: William Mills; David Recordon; OAuth WG; [email-masked]
	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,

		
		
		EHL

			

				 

				 
				EHL

				

					

					

					

					 

					 

					

					

					 

					
					EHL
					
					------ Forwarded  Message

					

		
		force_auth

		 

					

					Hi Eran,

					

					
					Examples:

					

					
					Regards,

	-- 
	Colin Snover