Subject: [OAUTH-WG] Issue: 'username' parameter proposal

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 11:55:50 -0700

Evan Gilbert proposed a 'username' request parameter to allow the client to
limit the end user to authenticate using the provided authorization server
identifier. The proposal has not been discussed or supported by others, and
has not received a security review.

Proposal: Obtain further discussion and support from others, as well as a
security review of the proposal. Otherwise, do nothing.

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 19 Apr 2010 08:33:56 -0700

More details on this enhancement.

Goal: Make sure you get an access token for the right user in immediate
mode.

Use case where we have problems if we don't have username parameter:

   1. Bob is logged into a web site as [email-masked].
   2. Mary (his wife) is logged into IDP on the same computer as
   [email-masked]
   3. A request is made to get an access token via the User-Agent flow in
   immediate mode (or with any redirect without prompting the user)
   4. -ob now has an access token for Mary and (posts activities, schedules
   events, gets contacts) as Mary
   5. Hilarity ensues

Secondary goal: Provide a hint for non-immediate mode

On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav <[email-masked]>wrote:

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 08:37:00 -0700

How can they both be logged in? I have never seen a case where two users can be both logged into to the same service at the same time...

EHL

On 4/19/10 8:33 AM, "Evan Gilbert" <[email-masked]> wrote:

Goal: Make sure you get an access token for the right user in immediate mode.

 1.  Bob is logged into a web site as [email-masked].
 2.  Mary (his wife) is logged into IDP on the same computer as [email-masked]
 3.  A request is made to get an access token via the User-Agent flow in immediate mode (or with any redirect without prompting the user)
 4.  -ob now has an access token for Mary and (posts activities, schedules events, gets contacts) as Mary
 5.  Hilarity ensues

On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav <[email-masked]> wrote:

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 19 Apr 2010 10:06:04 -0700

User 1 is logged into Client site
User 2 is logged into IDP site

This can happen quite frequently, as client sites often have long-lived
cookies and may only be visited by one user on a shared computer.

Right now client site has no way to ask for a token for User 1, and end
result will be that User 1 starts seeing User 2's data.

On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav <[email-masked]>wrote:

>  How can they both be logged in? I have never seen a case where two users
> can be both logged into to the same service at the same time...
>
> EHL
>
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 10:29:51 -0700

The scenario described by Evan is showing a real issue and the
username parameter is solving it. Not sure if there are other
implications, but definitely worth discussing.

Marius

On Mon, Apr 19, 2010 at 10:06 AM, Evan Gilbert <[email-masked]> wrote:
>> Bob is logged into a web site as [email-masked].
>> Mary (his wife) is logged into IDP on the same computer as [email-masked]
>> A request is made to get an access token via the User-Agent flow in
>> -ob now has an access token for Mary and (posts activities, schedules
>> Hilarity ensues

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 10:58:44 -0700

Thanks. That makes sense.

My concern is that the client will ask for a specific username but an attacker will change that request before it hits the server. The server then asks the (wrong) user to authenticate and returns a token. The client has no way of knowing it got an access token for the wrong user. Does requiring that the server returns the token with the username solves this? Is this a real issue?

I have no objections to this proposal but wanted to see some discussion and support from others before adding it to the spec.

EHL

From: Evan Gilbert [mailto:[email-masked]]
Sent: Monday, April 19, 2010 10:06 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal

This can happen quite frequently, as client sites often have long-lived cookies and may only be visited by one user on a shared computer.

Right now client site has no way to ask for a token for User 1, and end result will be that User 1 starts seeing User 2's data.

On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
How can they both be logged in? I have never seen a case where two users can be both logged into to the same service at the same time...

EHL

On 4/19/10 8:33 AM, "Evan Gilbert" <[email-masked]<http://[email-masked]>> wrote:
More details on this enhancement.

 1.  Bob is logged into a web site as [email-masked]<http://[email-masked]>.
 2.  Mary (his wife) is logged into IDP on the same computer as [email-masked]<http://[email-masked]>
 3.  A request is made to get an access token via the User-Agent flow in immediate mode (or with any redirect without prompting the user)
 4.  -ob now has an access token for Mary and (posts activities, schedules events, gets contacts) as Mary
 5.  Hilarity ensues

On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav <[email-masked]<http://[email-masked]>> wrote:

EHL

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 19 Apr 2010 21:18:55 +0200

in oder to prevent such attacks, one could sign the inbound request

regards,
Torsten.

Am 19.04.2010 19:58, schrieb Eran Hammer-Lahav:
> My concern is that the client will ask for a specific username but an 
> attacker will change that request before it hits the server. The 
> server then asks the (wrong) user to authenticate and returns a token. 
> The client has no way of knowing it got an access token for the wrong 
> user. Does requiring that the server returns the token with the 
> username solves this? Is this a real issue?
>
> I have no objections to this proposal but wanted to see some 
> discussion and support from others before adding it to the spec.
>
> EHL
>
> *From:* Evan Gilbert [mailto:[email-masked]]
> *Sent:* Monday, April 19, 2010 10:06 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Issue: 'username' parameter proposal
>
> This can happen quite frequently, as client sites often have 
> long-lived cookies and may only be visited by one user on a shared 
> computer.
>
> Right now client site has no way to ask for a token for User 1, and 
> end result will be that User 1 starts seeing User 2's data.
>
> On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> How can they both be logged in? I have never seen a case where two 
> users can be both logged into to the same service at the same time...
>
> EHL
>
>
>
>
>           [email-masked] <http://[email-masked]>
>        3. A request is made to get an access token via the User-Agent
>           flow in immediate mode (or with any redirect without
>           prompting the user)
>     On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav
>     <[email-masked] <http://[email-masked]>> wrote:
>
>     [email-masked] <http://[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 13:14:31 -0700

Which is something we decided not to do when we discussed the use of signatures.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Monday, April 19, 2010 12:19 PM
To: Eran Hammer-Lahav
Cc: Evan Gilbert; OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal

regards,
Torsten.

EHL

EHL

EHL

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 19 Apr 2010 22:34:20 +0200

Do you mean the thread "Signatures, Why?" 
(http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy)?

I cannot remember that there was a consensus not to use signatures on 
requests to the authorization server.

regards,
Torsten.

Am 19.04.2010 22:14, schrieb Eran Hammer-Lahav:
> *From:* Torsten Lodderstedt [mailto:[email-masked]]
> *Sent:* Monday, April 19, 2010 12:19 PM
> *To:* Eran Hammer-Lahav
> *Cc:* Evan Gilbert; OAuth WG
> [email-masked]  <mailto:[email-masked]>

---

From: Brian Eaton <[email-masked]>
Date: Mon, 19 Apr 2010 13:37:58 -0700

> requests to the authorization server.

I can. =)

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 19 Apr 2010 17:16:40 -0700

On Mon, Apr 19, 2010 at 10:58 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> attacker will change that request before it hits the server. The server then
> asks the (wrong) user to authenticate and returns a token. The client has no
> way of knowing it got an access token for the wrong user. Does requiring
> that the server returns the token with the username solves this? Is this a
> real issue?
>

This particular attack wasn't of concern to me, for a few of reasons:
- The request is HTTPS, hard to modify the request before it hits the server
- There are probably other, more dangerous attacks if you can modify request
parameters (for example, you can modify the client_id and get the user to
authorize the wrong app)

I'm willing to be convinced otherwise

>
>
> I have no objections to this proposal but wanted to see some discussion and
> support from others before adding it to the spec.
>
>
>
> EHL
>
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 20 Apr 2010 07:45:05 +0200

>> requests to the authorization server.

Can you please refer to the respective postings?

I wonder why a whole category of security measures is left out when 
designing a security sensitive protocol like OAUTH.

Eran gave an example of an attack that could be prevented using 
signatures, and there are others. Moreover, authenticating clients using 
public keys was an option in OAuth 1.0a. Why isn't that an option any 
longer?

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 20 Apr 2010 08:08:29 -0700

This attack is why the flow requires the client to present the callback it used again when getting the token.

EHL

From: Evan Gilbert [mailto:[email-masked]]
Sent: Monday, April 19, 2010 5:17 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal

On Mon, Apr 19, 2010 at 10:58 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Thanks. That makes sense.

This particular attack wasn't of concern to me, for a few of reasons:
- The request is HTTPS, hard to modify the request before it hits the server
- There are probably other, more dangerous attacks if you can modify request parameters (for example, you can modify the client_id and get the user to authorize the wrong app)

EHL

From: Evan Gilbert [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, April 19, 2010 10:06 AM
To: Eran Hammer-Lahav
Cc: OAuth WG

EHL

EHL

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 20 Apr 2010 09:36:07 -0700

Just to add some more context from experience, this "two users getting mixed
together" problem happens a lot in practice, esp. when you have a mix of
server-side and client-side auth. For instance, we saw this in our Facebook
Connect integration in Plaxo--normally the user connects and Plaxo stores
their session key in our databases, so when the user returns and logs in as
plaxo-user-123, we look it up and know that he's also facebook-user-456. But
some of Facebook Connect's UI widgets just look at the browser cookies on
facebook.com, where facebook-user-789 may be currently logged in (happens
all the time with shared computers at home). Thus we often had pages that
pulled some Facebook info server-side (as facebook-user-456) and some
client-side (as facebook-user-789) and it was very confusing and potentially
harmful (e.g. easy to accidentally post a story to the wrong account). The
solution would be for Plaxo to be able to pass facebook-user-456 down to the
JavaScript library, so it wouldn't just "silently auth" as a different
user--presumably, it would just treat it as if no one was logged into
facebook, if the passed-in user is not logged in. I think this is what Evan
is proposing we enable for OAuth, especially if we want it to work
client-side with immediate-mode (which I think we do).

Another related example of this problem we saw was with our photo-uploader
plug-in inside Picasa Desktop for sharing photos on Plaxo. During the upload
flow, it embeds a web browser, which lets you log in as plaxo-user-123, but
when it's done uploading, it opens a default web browser, where you might be
logged in as plaxo-user-456, leading again to a confusing mix-up of
identities. We solved this by appending the session-info of the user from
the embedded web browser on the URL of the main browser that gets opened, so
it can clobber the session as needed and maintain continuity of session.

Hope these experiences provide some useful and concrete context for
evaluating whether/how to support a username parameter in OAuth.

Thanks, js

On Tue, Apr 20, 2010 at 8:08 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> *Sent:* Monday, April 19, 2010 5:17 PM
>
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> - There are probably other, more dangerous attacks if you can modify
> request parameters (for example, you can modify the client_id and get the
> user to authorize the wrong app)
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 20 Apr 2010 10:23:20 -0700

I'm not aware of anyone arguing against this feature. The only issue is a full security review before we add it to the spec. If one of the security experts here can spend a few minutes to review this, we can move forward and add it to the draft.

EHL

From: Joseph Smarr [mailto:[email-masked]]
Sent: Tuesday, April 20, 2010 9:36 AM
To: Eran Hammer-Lahav
Cc: Evan Gilbert; OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal

Just to add some more context from experience, this "two users getting mixed together" problem happens a lot in practice, esp. when you have a mix of server-side and client-side auth. For instance, we saw this in our Facebook Connect integration in Plaxo--normally the user connects and Plaxo stores their session key in our databases, so when the user returns and logs in as plaxo-user-123, we look it up and know that he's also facebook-user-456. But some of Facebook Connect's UI widgets just look at the browser cookies on facebook.com<http://facebook.com>, where facebook-user-789 may be currently logged in (happens all the time with shared computers at home). Thus we often had pages that pulled some Facebook info server-side (as facebook-user-456) and some client-side (as facebook-user-789) and it was very confusing and potentially harmful (e.g. easy to accidentally post a story to the wrong account). The solution would be for Plaxo to be able to pass facebook-user-456 down to the JavaScript library, so it wouldn't just "silently auth" as a different user--presumably, it would just treat it as if no one was logged into facebook, if the passed-in user is not logged in. I think this is what Evan is proposing we enable for OAuth, especially if we want it to work client-side with immediate-mode (which I think we do).

Another related example of this problem we saw was with our photo-uploader plug-in inside Picasa Desktop for sharing photos on Plaxo. During the upload flow, it embeds a web browser, which lets you log in as plaxo-user-123, but when it's done uploading, it opens a default web browser, where you might be logged in as plaxo-user-456, leading again to a confusing mix-up of identities. We solved this by appending the session-info of the user from the embedded web browser on the URL of the main browser that gets opened, so it can clobber the session as needed and maintain continuity of session.

Hope these experiences provide some useful and concrete context for evaluating whether/how to support a username parameter in OAuth.

Thanks, js
On Tue, Apr 20, 2010 at 8:08 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
This attack is why the flow requires the client to present the callback it used again when getting the token.

EHL

To: Eran Hammer-Lahav
Cc: OAuth WG

EHL

EHL

EHL

---

From: Brian Eaton <[email-masked]>
Date: Tue, 20 Apr 2010 11:03:31 -0700

On Tue, Apr 20, 2010 at 10:23 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> I’m not aware of anyone arguing against this feature. The only issue is a
> full security review before we add it to the spec. If one of the security
> experts here can spend a few minutes to review this, we can move forward and
> add it to the draft.

I'd like to see some solutions mature in the wild.  Once we figure out
best practices in the real world, it'll be a lot easier to put good
policy on paper.

I just don't think we have a solid answer, and I don't want something
ending up in the spec that we will regret later.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 20 Apr 2010 11:16:23 -0700

Is that an objection to including a username parameter in the spec?

EHL

> -----Original Message-----
> From: Brian Eaton [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2010 11:04 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; OAuth WG
> > I'm not aware of anyone arguing against this feature. The only issue
> > is a full security review before we add it to the spec. If one of the
> > security experts here can spend a few minutes to review this, we can
> > move forward and add it to the draft.
> 
> I'd like to see some solutions mature in the wild.  Once we figure out best
> practices in the real world, it'll be a lot easier to put good policy on paper.
> 
> I just don't think we have a solid answer, and I don't want something ending
> up in the spec that we will regret later.
> 
> Cheers,
> Brian

---

From: Brian Eaton <[email-masked]>
Date: Tue, 20 Apr 2010 11:19:50 -0700

> Is that an objection to including a username parameter in the spec?

Damn skippy.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 20 Apr 2010 20:54:36 +0200

In my experiences, such a review takes much longer than a few minutes.

I think the whole specification should be subject to a comprehensive and 
in-depth security analysis (threat modeling, counter measures and so 
on). So why not adding this parameter and examine its implications in 
this context?

regards,
Torsten.

Am 20.04.2010 19:23, schrieb Eran Hammer-Lahav:
> *From:* Joseph Smarr [mailto:[email-masked]]
> *Sent:* Tuesday, April 20, 2010 9:36 AM
> *To:* Eran Hammer-Lahav
> Just to add some more context from experience, this "two users getting 
> mixed together" problem happens a lot in practice, esp. when you have 
> a mix of server-side and client-side auth. For instance, we saw this 
> in our Facebook Connect integration in Plaxo--normally the user 
> connects and Plaxo stores their session key in our databases, so when 
> the user returns and logs in as plaxo-user-123, we look it up and know 
> that he's also facebook-user-456. But some of Facebook Connect's UI 
> widgets just look at the browser cookies on facebook.com 
> <http://facebook.com>, where facebook-user-789 may be currently logged 
> in (happens all the time with shared computers at home). Thus we often 
> had pages that pulled some Facebook info server-side (as 
> facebook-user-456) and some client-side (as facebook-user-789) and it 
> was very confusing and potentially harmful (e.g. easy to accidentally 
> post a story to the wrong account). The solution would be for Plaxo to 
> be able to pass facebook-user-456 down to the JavaScript library, so 
> it wouldn't just "silently auth" as a different user--presumably, it 
> would just treat it as if no one was logged into facebook, if the 
> passed-in user is not logged in. I think this is what Evan is 
> proposing we enable for OAuth, especially if we want it to work 
> Another related example of this problem we saw was with our 
> photo-uploader plug-in inside Picasa Desktop for sharing photos on 
> Plaxo. During the upload flow, it embeds a web browser, which lets you 
> log in as plaxo-user-123, but when it's done uploading, it opens a 
> default web browser, where you might be logged in as plaxo-user-456, 
> leading again to a confusing mix-up of identities. We solved this by 
> appending the session-info of the user from the embedded web browser 
> on the URL of the main browser that gets opened, so it can clobber the 
> session as needed and maintain continuity of session.
>
> On Tue, Apr 20, 2010 at 8:08 AM, Eran Hammer-Lahav 
> This attack is why the flow requires the client to present the 
> callback it used again when getting the token.
>
> EHL
>
> *From:* Evan Gilbert [mailto:[email-masked] 
> <mailto:[email-masked]>]
> On Mon, Apr 19, 2010 at 10:58 AM, Eran Hammer-Lahav 
> request parameters (for example, you can modify the client_id and get 
> the user to authorize the wrong app)
>
>
>     *From:* Evan Gilbert [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     Right now client site has no way to ask for a token for User 1,
>     and end result will be that User 1 starts seeing User 2's data.
>
>            2. Mary (his wife) is logged into IDP on the same computer
>               as [email-masked] <http://[email-masked]>
>            3. A request is made to get an access token via the
>               User-Agent flow in immediate mode (or with any redirect
>               without prompting the user)
>            4. -ob now has an access token for Mary and (posts
>               activities, schedules events, gets contacts) as Mary
>            5. Hilarity ensues
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 20 Apr 2010 11:59:19 -0700

Because the rest of the spec did receive extensive review from both early adopters and from the previous drafts it borrowed from. Nothing so far is a new concept. The concept of an identity is new in OAuth, and while offers important benefits, should not be added to the spec when there are actual security concerns around it.

I raised a specific issue that was not addressed. Brian seems to have other concerns.

I don't like the policy of add-first-discuss-later.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Tuesday, April 20, 2010 11:55 AM
To: Eran Hammer-Lahav
Cc: [email-masked]; OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal

I think the whole specification should be subject to a comprehensive and in-depth security analysis (threat modeling, counter measures and so on). So why not adding this parameter and examine its implications in this context?

regards,
Torsten.

EHL

Thanks, js

EHL

To: Eran Hammer-Lahav
Cc: OAuth WG

EHL

EHL

EHL

OAuth mailing list

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Apr 2010 23:30:55 +0200

Am 20.04.2010 20:59, schrieb Eran Hammer-Lahav:
>
> Because the rest of the spec did receive extensive review from both 
> early adopters and from the previous drafts it borrowed from. Nothing 
> so far is a new concept. The concept of an identity is new in OAuth, 
> and while offers important benefits, should not be added to the spec 
> when there are actual security concerns around it.
>

My impression is that the specification has undergone significant 
changes since its first version and cannot be compared to its 
predecessor in terms of security.

Let me give you some examples.

I wonder if anyone security reviewed the introduction of refresh tokens 
to the User Agent Flow? From my point of view, refresh tokens are 
dangerous in this flow.

First of all, where should a JavaScript client store this token 
securely? If someone is able to steal the token, it can use it to obtain 
access tokens.

Steps:
1) legitimate client is granted access by the end user
2) client stores refresh token in local storage (?)
3) malicious software reads refresh token from local storage
4) malicious software obtains access token from the authorization server 
(no client secret required)
5) malicious software uses token or sends it to a central storage for 
further abuse

Second, the immediate mode has been introduced to the User Agent flow 
recently. I don't know exactly but my feeling is that a malicious 
software can steal tokens.

Steps:
1) malicious software initiated authorization flow using immediate=true 
and a stolen client_id
2) Assuming this client has been granted access by the end user of the 
particular computer, the authorization server directly respondes with 
tokens w/o user interaction. The user does not realize what is happening.
3) malicious software uses token or sends it to a central storage for 
further abuse

The only countermesure I see is the redirect URL verification, which 
seams to be optional: "If the client has previously registered a 
redirection URI with the
    authorization server".

> I raised a specific issue that was not addressed. Brian seems to have 

Other posts on the thread indicated a need for such an concept. We use 
such parameters, too.

I think, from a security standpoint, the problem is much more the 
immediate parameter then the username parameter. If the username is 
modified by an attacker, the user should see the username in 
authentication or authorization dialogs. So he/her can react. That's not 
the case in immediate mode, so there are only technical ways to prevent 
username modifications, HTTPS or signatures.

> I don't like the policy of add-first-discuss-later.

I don't like it either. But sometimes it is more efficient to make 
progress and discuss such aspects in-depth when reaching milestones.

regards,
Torsten.

> *Sent:* Tuesday, April 20, 2010 11:55 AM
> *To:* Eran Hammer-Lahav
> *Cc:* [email-masked]; OAuth WG
> I think the whole specification should be subject to a comprehensive 
> and in-depth security analysis (threat modeling, counter measures and 
> so on). So why not adding this parameter and examine its implications 
> in this context?
>
> regards,
> Torsten.
>

---

From: Eve Maler <[email-masked]>
Date: Wed, 21 Apr 2010 16:43:04 -0700

Tacking this response to the end of the thread for lack of a better place to do it: The name "username" seems not quite apt in the case of an autonomous client that isn't representing an end-user. Would "identifier" be better? (Actually, it sort of reminds me of SAML's "SessionIndex"...) Or would the parameter be reserved for user-delegation flows?

Speaking of autonomous clients, Section 2.2 -- among possibly other places -- states that an autonomous client is also the resource owner, but that's not always the case, is it? The client might be seeking access on behalf of itself. (FWIW, I made roughly this same comment on David's first draft on March 21, and he agreed with my suggested fix at the time.)

	Eve

On 21 Apr 2010, at 2:30 PM, Torsten Lodderstedt wrote:

> My impression is that the specification has undergone significant changes since its first version and cannot be compared to its predecessor in terms of security. 
> 
> I wonder if anyone security reviewed the introduction of refresh tokens to the User Agent Flow? From my point of view, refresh tokens are dangerous in this flow. 
> 
> First of all, where should a JavaScript client store this token securely? If someone is able to steal the token, it can use it to obtain access tokens.
> 
> Steps:
> 4) malicious software obtains access token from the authorization server (no client secret required)
> 5) malicious software uses token or sends it to a central storage for further abuse 
> 
> Second, the immediate mode has been introduced to the User Agent flow recently. I don't know exactly but my feeling is that a malicious software can steal tokens.
> 
> Steps:
> 1) malicious software initiated authorization flow using immediate=true and a stolen client_id
> 2) Assuming this client has been granted access by the end user of the particular computer, the authorization server directly respondes with tokens w/o user interaction. The user does not realize what is happening.
> 3) malicious software uses token or sends it to a central storage for further abuse 
> 
> The only countermesure I see is the redirect URL verification, which seams to be optional: "If the client has previously registered a redirection URI with the
>    authorization server".
>  
>>  
> Other posts on the thread indicated a need for such an concept. We use such parameters, too. 
> 
> I think, from a security standpoint, the problem is much more the immediate parameter then the username parameter. If the username is modified by an attacker, the user should see the username in authentication or authorization dialogs. So he/her can react. That's not the case in immediate mode, so there are only technical ways to prevent username modifications, HTTPS or signatures. 
> 
>>  
>> I don’t like the policy of add-first-discuss-later.
> 
> I don't like it either. But sometimes it is more efficient to make progress and discuss such aspects in-depth when reaching milestones.
> 
> regards,
> Torsten.
> 
>>  
>> EHL
>>  
>> I’m not aware of anyone arguing against this feature. The only issue is a full security review before we add it to the spec. If one of the security experts here can spend a few minutes to review this, we can move forward and add it to the draft.
>>  
>> EHL
>>  
>> Just to add some more context from experience, this "two users getting mixed together" problem happens a lot in practice, esp. when you have a mix of server-side and client-side auth. For instance, we saw this in our Facebook Connect integration in Plaxo--normally the user connects and Plaxo stores their session key in our databases, so when the user returns and logs in as plaxo-user-123, we look it up and know that he's also facebook-user-456. But some of Facebook Connect's UI widgets just look at the browser cookies on facebook.com, where facebook-user-789 may be currently logged in (happens all the time with shared computers at home). Thus we often had pages that pulled some Facebook info server-side (as facebook-user-456) and some client-side (as facebook-user-789) and it was very confusing and potentially harmful (e.g. easy to accidentally post a story to the wrong account). The solution would be for Plaxo to be able to pass facebook-user-456 down to the JavaScript library, so it wouldn't just "silently auth" as a different user--presumably, it would just treat it as if no one was logged into facebook, if the passed-in user is not logged in. I think this is what Evan is proposing we enable for OAuth, especially if we want it to work client-side with immediate-mode (which I think we do).
>>  
>> On Tue, Apr 20, 2010 at 8:08 AM, Eran Hammer-Lahav <[email-masked]> wrote:
>> On Mon, Apr 19, 2010 at 10:58 AM, Eran Hammer-Lahav <[email-masked]> wrote:
>> On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav <[email-masked]> wrote:
>> A request is made to get an access token via the User-Agent flow in immediate mode (or with any redirect without prompting the user)
>> -ob now has an access token for Mary and (posts activities, schedules events, gets contacts) as Mary
>> Hilarity ensues
>> 

Eve Maler
[email-masked]
http://www.xmlgrrl.com/blog

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 21 Apr 2010 17:12:40 -0700

This is part of the delegation flows so username should be just fine...

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eve Maler
Sent: Wednesday, April 21, 2010 4:43 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal

          Eve

Steps:

Steps:

regards,
Torsten.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Tuesday, April 20, 2010 11:55 AM
To: Eran Hammer-Lahav
Cc: [email-masked]<mailto:[email-masked]>; OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal

regards,
Torsten.

EHL

Just to add some more context from experience, this "two users getting mixed together" problem happens a lot in practice, esp. when you have a mix of server-side and client-side auth. For instance, we saw this in our Facebook Connect integration in Plaxo--normally the user connects and Plaxo stores their session key in our databases, so when the user returns and logs in as plaxo-user-123, we look it up and know that he's also facebook-user-456. But some of Facebook Connect's UI widgets just look at the browser cookies on facebook.com<http://facebook.com/>, where facebook-user-789 may be currently logged in (happens all the time with shared computers at home). Thus we often had pages that pulled some Facebook info server-side (as facebook-user-456) and some client-side (as facebook-user-789) and it was very confusing and potentially harmful (e.g. easy to accidentally post a story to the wrong account). The solution would be for Plaxo to be able to pass facebook-user-456 down to the JavaScript library, so it wouldn't just "silently auth" as a different user--presumably, it would just treat it as if no one was logged into facebook, if the passed-in user is not logged in. I think this is what Evan is proposing we enable for OAuth, especially if we want it to work client-side with immediate-mode (which I think we do).

Thanks, js

EHL

To: Eran Hammer-Lahav
Cc: OAuth WG

EHL

EHL

On 4/19/10 8:33 AM, "Evan Gilbert" <[email-masked]<http://[email-masked]/>> wrote:
More details on this enhancement.

 1.  Bob is logged into a web site as [email-masked]<http://[email-masked]/>.
 2.  Mary (his wife) is logged into IDP on the same computer as [email-masked]<http://[email-masked]/>
 3.  A request is made to get an access token via the User-Agent flow in immediate mode (or with any redirect without prompting the user)
 4.  -ob now has an access token for Mary and (posts activities, schedules events, gets contacts) as Mary
 5.  Hilarity ensues

On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav <[email-masked]<http://[email-masked]/>> wrote:

EHL

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

OAuth mailing list

Eve Maler
[email-masked]<mailto:[email-masked]>
http://www.xmlgrrl.com/blog

---

From: Eve Maler <[email-masked]>
Date: Wed, 21 Apr 2010 18:35:19 -0700

Thanks!

On 21 Apr 2010, at 5:12 PM, Eran Hammer-Lahav wrote:

> This is part of the delegation flows so username should be just fine…
>  
> EHL
>  

Eve Maler
[email-masked]

---

From: Eve Maler <[email-masked]>
Date: Fri, 23 Apr 2010 07:21:06 -0700

Regarding the second comment I made below: I realized last night that Sections 3.7.1 and 3.7.2 get this more correct, by saying that an autonomous client represents a "separate resource owner". So Section 2.2 definitely needs a slight change, from:

"...and autonomous flows where the client is acting for itself (the client is also the resource owner)."

to something like:

"...and autonomous flows where the client is acting on behalf of a different resource owner."

Thanks,

	Eve

Eve Maler
[email-masked]

---

From: "Foiles, Doug" <[email-masked]>
Date: Sun, 25 Apr 2010 10:34:45 -0700

I have a bit of confusion on the Autonomous Client Flows … and specifically related to Eve’s comment below that suggests to me that the autonomous client is NOT ALWAYS the resource owner.

Can the Autonomous Client Flows support clients that ARE NOT the actual resource owner?  For example for an Assertion Flow where the Subject of the SAML assertion is a user identity (and the resource owner) and not that of the client.

Is the intent of the Client Credentials Flow to support something like Google’s “OAuth for Google Apps domains” 2 Legged OAuth use case?  http://code.google.com/apis/accounts/docs/OAuth.html.

If the Autonomous Client Flows support clients that can act on behalf a resource owner that is not themselves  … it then seems the resource owner must provide some level of consent outside the OAuth specific flow. 

Thanks.

Doug

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eve Maler
Sent: Friday, April 23, 2010 7:21 AM
To: OAuth WG
Subject: [OAUTH-WG] Autonomous clients and resource owners (editorial)

to something like:

Thanks,

            Eve

            Eve

Eve Maler

[email-masked]

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 26 Apr 2010 14:17:43 -0700

+1.

Our primary use-cases for the assertion flow are for clients acting on behalf of users, and not autonomously.   I believe Eran already has this on his list of feedback when the assertion flow gets edited.

We also have need for a 2 legged Oauth model, and are looking at the client credentials flow for exactly that purpose.

-cmort

On 4/25/10 10:34 AM, "Foiles, Doug" <[email-masked]> wrote:

I have a bit of confusion on the Autonomous Client Flows ... and specifically related to Eve's comment below that suggests to me that the autonomous client is NOT ALWAYS the resource owner.

Is the intent of the Client Credentials Flow to support something like Google's "OAuth for Google Apps domains" 2 Legged OAuth use case?  http://code.google.com/apis/accounts/docs/OAuth.html.

If the Autonomous Client Flows support clients that can act on behalf a resource owner that is not themselves  ... it then seems the resource owner must provide some level of consent outside the OAuth specific flow.

Thanks.

Doug

to something like:

Thanks,

            Eve

            Eve

Eve Maler

[email-masked]

---

From: Eve Maler <[email-masked]>
Date: Mon, 26 Apr 2010 16:51:56 -0700

In UMA, we've got use cases for "person-to-service" sharing that can act much like the user-delegated OAuth patterns of today (essentially introducing two services to interact on your own behalf), and also use cases for "person-to-person" sharing that involve a "separate resource owner", hence our interest in the autonomous client pattern or a variant thereof. We allow the original resource owner (we call them an authorizing user) to set policies asynchronously at the authorization manager (a sort of enhanced/user-centric authz server) that govern whether a requesting party can ultimately get a token. So in our case, this is how the resource owner gives consent outside the flow.

(BTW, the word "ownership" gets tricky in talking about resource access and other "property rights", which are famously described as a "bundle of sticks" to show that different parties might have different subsets of rights. E.g., in some UMA use cases, the authorizing user obviously has the right to throttle or audit who can see certain data, but they don't have the right to actually set the value of that data. Reputation data, such as a credit score or a third-party certification, is a classic example. It's hard to describe the data subject in this case as a total "resource owner"...)

	Eve

Eve Maler
[email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 27 Apr 2010 07:23:08 +0200

+1

we need the assertion flow for the same purpose. Can we add a variant of 
the flow to section "End User Credentials Flows"?

regards,
Torsten.

Am 26.04.2010 23:17, schrieb Chuck Mortimore:
> +1.
>
> Our primary use-cases for the assertion flow are for clients acting on 
> behalf of users, and not autonomously.   I believe Eran already has 
> this on his list of feedback when the assertion flow gets edited.
>
> We also have need for a 2 legged Oauth model, and are looking at the 
> client credentials flow for exactly that purpose.
>
> -cmort
>
>
>     I have a bit of confusion on the Autonomous Client Flows ... and
>     specifically related to Eve's comment below that suggests to me
>     that the autonomous client is NOT ALWAYS the resource owner.
>
>     Can the Autonomous Client Flows support clients that ARE NOT the
>     actual resource owner?  For example for an Assertion Flow where
>     the Subject of the SAML assertion is a user identity (and the
>     resource owner) and not that of the client.
>
>     Is the intent of the Client Credentials Flow to support something
>     like Google's "OAuth for Google Apps domains" 2 Legged OAuth use
>     case? http://code.google.com/apis/accounts/docs/OAuth.html.
>
>     If the Autonomous Client Flows support clients that can act on
>     behalf a resource owner that is not themselves  ... it then seems
>     the resource owner must provide some level of consent outside the
>     OAuth specific flow.
>
>     Thanks.
>
>     Doug
>
>
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Eve Maler
>     *Sent:* Friday, April 23, 2010 7:21 AM
>     *To:* OAuth WG
>     *Subject:* [OAUTH-WG] Autonomous clients and resource owners
>     (editorial)
>
>
>     Regarding the second comment I made below: I realized last night
>     that Sections 3.7.1 and 3.7.2 get this more correct, by saying
>     that an autonomous client represents a "separate resource owner".
>     So Section 2.2 definitely needs a slight change, from:
>
>
>
>     "...and autonomous flows where the client is acting for itself
>     (the client is also the resource owner)."
>
>
>
>     to something like:
>
>
>
>     Tacking this response to the end of the thread for lack of a
>     better place to do it: The name "username" seems not quite apt in
>     the case of an autonomous client that isn't representing an
>     end-user. Would "identifier" be better? (Actually, it sort of
>     reminds me of SAML's "SessionIndex"...) Or would the parameter be
>     reserved for user-delegation flows?
>
>
>
>     Speaking of autonomous clients, Section 2.2 -- among possibly
>     other places -- states that an autonomous client is also the
>     resource owner, but that's not always the case, is it? The client
>     might be seeking access on behalf of itself. (FWIW, I made roughly
>     this same comment on David's first draft on March 21, and he
>     agreed with my suggested fix at the time.)
>
>
>
>                 Eve
>
>
>
>     Eve Maler
>
>     [email-masked]
>

---

From: Brian Eaton <[email-masked]>
Date: Mon, 26 Apr 2010 23:33:17 -0700

>From my perspective, the main thing is that the assertion flow can be
used to connect existing authentication systems with APIs that are
using OAuth2 for authorization.

This will let us leverage existing trust relationships across systems.

Note that this breaks, however, if the flow returns a refresh token.
Refresh tokens are a new trust relationship, and they require
additional user/administrator involvement to manage.

Cheers,
Brian

On Mon, Apr 26, 2010 at 10:23 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> +1
>
> we need the assertion flow for the same purpose. Can we add a variant of the
> flow to section "End User Credentials Flows"?
>
> regards,
> Torsten.
>
> behalf of users, and not autonomously.   I believe Eran already has this on
> his list of feedback when the assertion flow gets edited.
>
> We also have need for a 2 legged Oauth model, and are looking at the client
> credentials flow for exactly that purpose.
>
> -cmort
>
>
> I have a bit of confusion on the Autonomous Client Flows … and specifically
> related to Eve’s comment below that suggests to me that the autonomous
> client is NOT ALWAYS the resource owner.
>
> Can the Autonomous Client Flows support clients that ARE NOT the actual
> resource owner?  For example for an Assertion Flow where the Subject of the
> SAML assertion is a user identity (and the resource owner) and not that of
> the client.
>
> Is the intent of the Client Credentials Flow to support something like
> Google’s “OAuth for Google Apps domains” 2 Legged OAuth use case?
>  http://code.google.com/apis/accounts/docs/OAuth.html.
>
> If the Autonomous Client Flows support clients that can act on behalf a
> resource owner that is not themselves  … it then seems the resource owner
> must provide some level of consent outside the OAuth specific flow.
>
> Thanks.
>
> Doug
>
>
> Regarding the second comment I made below: I realized last night that
> Sections 3.7.1 and 3.7.2 get this more correct, by saying that an autonomous
> client represents a "separate resource owner". So Section 2.2 definitely
> needs a slight change, from:
>
>
>
> Tacking this response to the end of the thread for lack of a better place to
> do it: The name "username" seems not quite apt in the case of an autonomous
> client that isn't representing an end-user. Would "identifier" be better?
> (Actually, it sort of reminds me of SAML's "SessionIndex"...) Or would the
> parameter be reserved for user-delegation flows?
>
>
>
> Speaking of autonomous clients, Section 2.2 -- among possibly other places
> -- states that an autonomous client is also the resource owner, but that's
> not always the case, is it? The client might be seeking access on behalf of
> itself. (FWIW, I made roughly this same comment on David's first draft on
> March 21, and he agreed with my suggested fix at the time.)
>
>
>
>             Eve
>
>
>
> Eve Maler
>
> [email-masked]
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 27 Apr 2010 18:00:08 +0200

returning access token would suffice in this flow, from my point of  
view.

regards,
Torsten.

Am 27.04.2010 um 08:33 schrieb Brian Eaton <[email-masked]>:

>> this on
>> actual
>> like
>> behalf a
>> From: [email-masked] [mailto:[email-masked]] On  
>> Behalf Of
>> Eve Maler
>> "...and autonomous flows where the client is acting for itself (the  
>> client
>> is also the resource owner)."
>>
>>
>>
>> to something like:
>>
>>
>>
>> "...and autonomous flows where the client is acting on behalf of a  
>> different
>> resource owner."
>>
>>
>>
>> Thanks,
>>
>>
>>
>>             Eve
>>
>>
>>

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 27 Apr 2010 09:05:45 -0700

Same here - we don't intend to issue refresh tokens for either of these flows, and we'll only be accepting 1 time use assertions.

-cmort
________________________________________
From: Torsten Lodderstedt [[email-masked]]
Sent: Tuesday, April 27, 2010 9:00 AM
To: Brian Eaton
Cc: Chuck Mortimore; Foiles, Doug; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)

regards,
Torsten.

---

From: "Keenan, Bill" <[email-masked]>
Date: Tue, 27 Apr 2010 12:14:10 -0700

With Doug in an all day mtg, we have not sync'd on this...so one of us
may respond again on this topic.

I think I am +1 w/ Brian E.

In the flow from SAML gateway to STS to protected resource, I don't see
caching both an access and refresh token as getting me any efficiency.
Certainly, it adds complexity to regression testing.

I appreciate the desire for symmetry on the set of flows...refresh token
seems like a place for asymmetry.

BillK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Chuck Mortimore
Sent: Tuesday, April 27, 2010 9:06 AM
To: Torsten Lodderstedt; Brian Eaton
Cc: Foiles, Doug; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
(editorial)

Same here - we don't intend to issue refresh tokens for either of these
flows, and we'll only be accepting 1 time use assertions.

-cmort
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
(editorial)

regards,
Torsten.

Am 27.04.2010 um 08:33 schrieb Brian Eaton <[email-masked]>:

>> I have a bit of confusion on the Autonomous Client Flows ... and spe
>> cifically
>> related to Eve's comment below that suggests to me that the autono
>> mous
>> Google's "OAuth for Google Apps domains" 2 Legged OAuth use ca
>> se?
>> resource owner that is not themselves  ... it then seems the resourc
>> e owner

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 27 Apr 2010 17:46:29 -0700

Refresh token was explicitly removed from the suggestion I made for assertion flow.   I'd be curious if others on the list see a need for it...?

Eran - do you expect to make edits to the assertion flow before pushing the working group draft?

-cmort

On 4/27/10 12:14 PM, "Keenan, Bill" <[email-masked]> wrote:

BillK

-----Original Message-----

-cmort

regards,
Torsten.