Subject: [OAUTH-WG] 'immediate' without identity

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 22 May 2010 23:07:05 -0700

Are there use cases for the 'immediate' parameter where a companion parameter for identity (e.g. 'username') is not needed or required? The purpose of the 'immediate' parameter is for the authorization server to authenticate the end user via some automatic means (usually a cookie) and check if an access token was already issued for that end user / client identifier combination.

This parameter is only useful when the client is already familiar with the end user (not the first time it seeks authorization), in which case, it should pass that information along to make sure the same user is logged into the authorization server.

If all the use cases require both, we should include both and make one required if the other is present.

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 23 May 2010 11:37:57 +0200

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

How does the client determine the end-user's identity (at the AS) in the 
initial authorization transaction? Will you introduce a respective 
response parameter?

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 23 May 2010 08:40:39 -0700

Yep, we need to take care of that too. What I'm getting at is that it seems like we need a better story about identity and 'immediate' in OAuth which seems to be more about the use cases of the OpenID Connect proposal than the OAuth core proposal. However, since these use cases are very important to many of the participants here in the context of implementing *OAuth* (not OpenID), we should provide some support.

What I'm thinking is to take the 'immediate' parameter out, and write a simple OAuth identity extension spec where it will be included, as well as the requested 'username' parameter (or whatever we decide to call it). It will not include any discovery (which is probably going to be another spec), just how to establish and verify identity using OAuth once you know where the token endpoint is and have client credentials (registered).

But back to my original email, what are the use cases for 'immediate' without identity?

EHL

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Sunday, May 23, 2010 2:38 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] 'immediate' without identity
> 
> >
> > Are there use cases for the 'immediate' parameter where a companion
> parameter for identity (e.g. 'username') is not needed or required? The
> purpose of the 'immediate' parameter is for the authorization server to
> authenticate the end user via some automatic means (usually a cookie) and
> check if an access token was already issued for that end user / client
> identifier combination.
> >
> > This parameter is only useful when the client is already familiar with the
> end user (not the first time it seeks authorization), in which case, it should
> pass that information along to make sure the same user is logged into the
> authorization server.
> >
> initial authorization transaction? Will you introduce a respective response
> parameter?
> 
> regards,
> Torsten.

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 24 May 2010 10:10:10 +1000

> Are there use cases for the 'immediate' parameter where a companion parameter for identity (e.g. 'username') is not needed or required?

Yes. A client app might want to offer a bit of personalization if it can provide it silently (eg by reading a protected resource on a visitor’s behalf), regardless of whether or not it has identified the visitor yet.

I don't think it is necessary (or helpful) to tie "immediate" and "username" together.

-- 
James Manger

---

From: Dick Hardt <[email-masked]>
Date: Sun, 23 May 2010 20:01:25 -0700

> But back to my original email, what are the use cases for 'immediate' without identity?

The client may not have any indication of which user it is, but want to check if it is a user they already know. They can do a check immediate, get the token, then make an API call to see which user it is.

This would be the case if the user has used the client, but is now on a different machine or has cleared cookies.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 23 May 2010 22:32:02 -0700

How does this work if there are two people using the same computer and the other user is the one currently logged into the server?

I think the client should be required to tell the server who the user is when using immediate to avoid this problem.

EHL

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Sunday, May 23, 2010 8:01 PM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; OAuth WG ([email-masked])
> The client may not have any indication of which user it is, but want to check if
> it is a user they already know. They can do a check immediate, get the token,
> then make an API call to see which user it is.
> 
> This would be the case if the user has used the client, but is now on a
> different machine or has cleared cookies.
> 
> -- Dick

---

From: Dick Hardt <[email-masked]>
Date: Mon, 24 May 2010 07:34:35 -0700

You were looking for use cases for immediate without identity. 

I agree that *if* the client does know the user, then it should tell the server. Are you saying that if the client does not know the user it should not use immediate?

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 24 May 2010 08:55:20 -0700

> Sent: Monday, May 24, 2010 7:35 AM
> To: Eran Hammer-Lahav
> I agree that *if* the client does know the user, then it should tell the server.
> Are you saying that if the client does not know the user it should not use
> immediate?

I think the server should reject an immediate request without a username. Otherwise the server will be giving the client an access token that belongs to another user.

Let me rephrase this: is anyone here planning on supporting 'immediate' for cases where the client don't know who the user is and just wants access to whoever last logged into the server? Basically ignoring  the chance more than one user is using the computer, or trusting the client to then get the username and ask the user if it is them (after getting an access token for someone else and making at least one call for their identity).

EHL

> > How does this work if there are two people using the same computer and
> the other user is the one currently logged into the server?
> >
> >> The client may not have any indication of which user it is, but want
> >> to check if it is a user they already know. They can do a check
> >> immediate, get the token, then make an API call to see which user it is.
> >>
> >> This would be the case if the user has used the client, but is now on
> >> a different machine or has cleared cookies.
> >>
> >> -- Dick
> >

---

From: Luke Shepard <[email-masked]>
Date: Mon, 24 May 2010 08:56:26 -0700

+1 to Dick.

Eran - this is a very common use case. You can't require the client to know who the user is ahead of time.

If the other user is the one currently logged into the server, then that's the ID that is returned. It's up to the client to figure out what to do - in most cases, they will treat the identity returned from the server as authoritative. That's what single sign on is.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 24 May 2010 09:03:53 -0700

Seems like bad server policy to me. By limiting immediate mode to times when the client knows who the user is, the server keeps control over when to automatically issue access tokens to clients. After all, the server can use immediate mode even when not asked for.

The scenario you are talking about is the rare case of a user using a client for the first time on a given computer. This doesn't happen often.

I am not suggesting that the spec will mandate usernames (thought I would never write a server allowing immediate without a username). I am simply asking if there are use cases where the two are completely unrelated. That is, unrelated enough to live in separate specifications (since the username/identity part is going to live elsewhere).

BTW, single sign on is all about identity, even when implicit. You are suggesting a single sign on system in which no one cares if the same identity is maintained across applications. Odd.

EHL

> From: Luke Shepard [mailto:[email-masked]]
> Sent: Monday, May 24, 2010 8:56 AM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG ([email-masked])
> If the other user is the one currently logged into the server, then that's the
> ID that is returned. It's up to the client to figure out what to do - in most
> cases, they will treat the identity returned from the server as authoritative.
> That's what single sign on is.
>

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 24 May 2010 12:31:28 -0400

I'm still a newbie to the OAuth and WRAP discussions, so please bear with me.

In Section 2.2, draft-ietf-oauth-v2-05 states that the access token is basicaly an opaque structure to the client, but which can have some "internal structure" (having meaning to the authz server and resource server):

] Access token strings can use any internal structure agreed upon
] between the authorization server and the resource server, but their
] structure is opaque to the client.  Since the access token provides
] the client access to the protected resource for the life of the
] access token (or until revoked), the authorization server should
] issue access tokens which expire within an appropriate time, usually
] much shorter than the duration of the access grant.

I was wondering how true this is? 

I want to use a Kerberos v5 ticket as the token (base encoded). The OAuth Client need not understand this structure, but could simply pass it down to the Kerberos-client (in the OS or in the browser).

Then within this token (now a Kerberos ticket), the ticket fields would contain matching entries (as far as possible) to the OAuth token parameters (eg. expires_in, token_secret, etc).

For the cryptographic tokens (Section 5.3), I would then use the session-key in the ticket to compute he HMAC.

Would this work?  Any suggestions?

/thomas/

---

From: Dick Hardt <[email-masked]>
Date: Mon, 24 May 2010 11:18:04 -0700

> I think the server should reject an immediate request without a username. Otherwise the server will be giving the client an access token that belongs to another user.

Now I understand. I agree.

-- Dick

---

From: Luke Shepard <[email-masked]>
Date: Mon, 24 May 2010 12:44:38 -0700

Suppose the client does not have a username - say, because the cookie expired. What is the appropriate behavior?

Would you require the client to spawn a popup or redirect to a full page auth every time a user revisits their site? This doesn't make sense.

Under what circumstances do you think the client gives an access token that belongs to another user? If the user is logged into the service provider, then they can get that access token anyway by just visiting the service provider ...

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 24 May 2010 21:51:36 +0200

> But back to my original email, what are the use cases for 'immediate' without identity?

As James pointed out, a client can generally use the immediate parameter 
to offer "a bit of personalization if it can provide it silently".

Having that in mind, I see the following scenarios:

Classical OAuth

A classical OAuth client would probably have its own user management and 
use OAuth to get access to a end-users resources on other sites. It does 
not need to know (and probably shall not know) the user's identity on 
the other sites. The immediate parameter could be used w/o identity in 
the following situations:

- the client does not want to store refresh tokens and tries to aquire 
an access token after login
- the authz server does not issue refresh tokens, but stores end-user 
authorizations and issues access tokens based on it
- the client is authorized automatically by a security policy (company 
internal applications)

OpenID Connect

In this context, the OAuth services is used to obatin the end-user's 
identity. So how should the client know the identity upfront? This would 
be comparable to an OpenID RP knowing the user id before issuing the 
authentication request.
The immediate parameter works the same way as the openid.mode 
"checkid_immediate". Typically the client will try to acquire an 
end-users identity, if already established, in order to (optionally) 
personalize the site. We do this for several portal sites (w/ our 
proprietary SSO protocol). If this fails and the end-user enters a 
protected region of the sites afterwards, user authentication is 
enforced by ommiting the immediate parameter. Yes, if two users use the 
same computer, the "wrong" identity could be used here. But that's, from 
my point of view, a characteristics of single sign on. That's why single 
sign-on should be accompanied by single logout.

My conclusion: There are several use cases where the client does not 
need (or is unable) to know the user's identity but could use the 
immediate mode.

In contrast, I think the username is useful in several situations w/o 
the immediate mode. For example, if the client already possesses a token 
for a particular user and wants to acquire another token for another 
resource of that particular user. The client could ensure the users 
identity match by passing the username to the authorization flow.

regards,
Torsten.

>>> If all the use cases require both, we should include both and make one
>>>        
>> required if the other is present.
>>      
>>> EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 24 May 2010 13:05:04 -0700

I am more interested in how you plan to address the (long term) security and privacy issue: who is responsible to prevent one user in getting an access token for another in a shared computer environment. As long as the user goes to facebook.com, you show they who is logged in clearly, so if it is not them, they can log out.

But using immediate without a username, it sounds to me like you expect the client to do the right thing. Is this how you plan to address this? Ask the client to find out whose access token it got, display it to the user, and allow them to correct this? Especially given that at this point the client account is already "paired" with the access token.

EHL

On 5/24/10 12:44 PM, "Luke Shepard" <[email-masked]> wrote:

---

From: Dick Hardt <[email-masked]>
Date: Mon, 24 May 2010 22:52:38 -0700

Not sure why you want to pull the OAuth token parameters from the Kerberos
token.

Are you envisioning the Protected Resource is a Kerberos Client?

On Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono <[email-masked]> wrote:

> In Section 2.2, draft-ietf-oauth-v2-05 states that the access token is
> basicaly an opaque structure to the client, but which can have some
> "internal structure" (having meaning to the authz server and resource
> server):
>
> I want to use a Kerberos v5 ticket as the token (base encoded). The OAuth
> Client need not understand this structure, but could simply pass it down to
> the Kerberos-client (in the OS or in the browser).
>
> Then within this token (now a Kerberos ticket), the ticket fields would
> contain matching entries (as far as possible) to the OAuth token parameters
> (eg. expires_in, token_secret, etc).
>
> For the cryptographic tokens (Section 5.3), I would then use the
> session-key in the ticket to compute he HMAC.
>

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 25 May 2010 11:29:26 -0400

The message flows within OAuth 2.0 are virtually identical to the Kerberos protocol (RFC4120 and RFC1510). There is also significant overlap in functionality (e.g. OAuth token matches the Kerberos ticket, the Refresh Token matches the TGT, etc).

Since there is a huge install-base of Kerberos out there, we want to figure out how to get the best interoperability between OAuth 2.0 and Kerberos. The scenario we think most probable is for organizations to stand-up an OAuth front-end, while retaining their Kerberos infra in the back-end.

What is the process in this Working Group to suggest ideas?  Should I just send to this list or write-up a draft?

Thanks.

/thomas/

__________________________________________

From: Dick Hardt [mailto:[email-masked]]
Sent: Tuesday, May 25, 2010 1:53 AM
To: Thomas Hardjono
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access token opaqueness question

Not sure why you want to pull the OAuth token parameters from the Kerberos token.

On Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono <[email-masked]<mailto:[email-masked]>> wrote:

/thomas/

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

---

From: Allen Tom <[email-masked]>
Date: Tue, 25 May 2010 18:42:15 -0700

Yahoo¹s security team has concerns regarding the immediate mode and shared
computers.

Consider the case where a browser based JS app is running in a browser tab
with credentials belonging to a particular user. While the app is still
running, the original user lets a friend borrow the browser. The friend
opens another tab, logs the original user out of the Service Provider, and
then logs in as different user using the friend¹s account.

At this point  the app is still running as the original user a different
tab. If the app¹s credentials expire, it could attempt an immediate request
to refresh them  which could then return the credentials belonging to the
2nd user. Since this is a JS app  the data that belongs to the first user
is already loaded, so the app could start co-mingling the data between the
two users.

At Yahoo, we call this scenario  ³crossing the streams² - and that¹s always
a really bad thing.

This scenario could be really disastrous if the SP has a login CSRF
vulnerability  meaning that an attacker can CSRF the victim¹s browser into
logging in with the attacker¹s account. This vulnerability would result in
the victim¹s data mixing with the Attacker.

One possible way to prevent this issue is for the client to pass the user¹s
identifier (or access token/refresh token/etc) in the immediate request.

Allen

On 5/24/10 1:05 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

> I am more interested in how you plan to address the (long term) security and
> privacy issue: who is responsible to prevent one user in getting an access
> token for another in a shared computer environment. As long as the user goes
> to facebook.com, you show they who is logged in clearly, so if it is not them,
> they can log out.
> 
> But using immediate without a username, it sounds to me like you expect the
> client to do the right thing. Is this how you plan to address this? Ask the
> client to find out whose access token it got, display it to the user, and
> allow them to correct this? Especially given that at this point the client
> account is already ³paired² with the access token.
> 
> EHL
> 
> 
>> Suppose the client does not have a username - say, because the cookie
>> expired. What is the appropriate behavior?
>> 
>> Would you require the client to spawn a popup or redirect to a full page auth
>> every time a user revisits their site? This doesn't make sense.
>> 
>> Under what circumstances do you think the client gives an access token that
>> belongs to another user? If the user is logged into the service provider,
>> then they can get that access token anyway by just visiting the service
>> provider ...
>> 
>>>> >> I think the server should reject an immediate request without a
>>>> username. Otherwise the server will be giving the client an access token
>>>> that belongs to another user.
>>> >

---

From: Luke Shepard <[email-masked]>
Date: Wed, 26 May 2010 07:29:18 -0700

This is a legitimate concern. One other possible way to prevent this issue is for the client to interpret the response, clear state, and refresh the page. This is the suggested way that many Connect sites handle the situation.

I don't disagree that it may be nice to allow the client to pass a username for verification. I think that it should not be required, as responsible clients can do the right thing. Requiring a username prevents a whole class of possible use cases - most notably, single sign on when you don't currently know the user at all.

On May 25, 2010, at 6:42 PM, Allen Tom wrote:

Yahoo’s security team has concerns regarding the immediate mode and shared computers.

Consider the case where a browser based JS app is running in a browser tab with credentials belonging to a particular user. While the app is still running, the original user lets a friend borrow the browser. The friend opens another tab, logs the original user out of the Service Provider, and then logs in as different user using the friend’s account.

At this point – the app is still running as the original user a different tab. If the app’s credentials expire, it could attempt an immediate request to refresh them – which could then return the credentials belonging to the 2nd user. Since this is a JS app – the data that belongs to the first user is already loaded, so the app could start co-mingling the data between the two users.

At Yahoo, we call this scenario  “crossing the streams” - and that’s always a really bad thing.

This scenario could be really disastrous if the SP has a login CSRF vulnerability – meaning that an attacker can CSRF the victim’s browser into logging in with the attacker’s account. This vulnerability would result in the victim’s data mixing with the Attacker.

One possible way to prevent this issue is for the client to pass the user’s identifier (or access token/refresh token/etc) in the immediate request.

Allen

On 5/24/10 1:05 PM, "Eran Hammer-Lahav" <[email-masked]<x-msg://77/[email-masked]>> wrote:

I am more interested in how you plan to address the (long term) security and privacy issue: who is responsible to prevent one user in getting an access token for another in a shared computer environment. As long as the user goes to facebook.com<http://facebook.com>, you show they who is logged in clearly, so if it is not them, they can log out.

But using immediate without a username, it sounds to me like you expect the client to do the right thing. Is this how you plan to address this? Ask the client to find out whose access token it got, display it to the user, and allow them to correct this? Especially given that at this point the client account is already “paired” with the access token.

EHL

On 5/24/10 12:44 PM, "Luke Shepard" <[email-masked]<x-msg://77/[email-masked]>> wrote:

On May 24, 2010, at 11:18 AM, Dick Hardt wrote:

>>> Cc: OAuth WG ([email-masked]<x-msg://77/[email-masked]>)
> [email-masked]<x-msg://77/[email-masked]>

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 May 2010 08:28:27 -0700

But that wasn't the question... it was whether the two are closely related (as in, should be defined in the same specification) and likely to be used together.

EHL

From: Luke Shepard [mailto:[email-masked]]
Sent: Wednesday, May 26, 2010 7:29 AM
To: Allen Tom
Cc: Eran Hammer-Lahav; Dick Hardt; OAuth WG
Subject: Re: [OAUTH-WG] 'immediate' without identity

Yahoo's security team has concerns regarding the immediate mode and shared computers.

Consider the case where a browser based JS app is running in a browser tab with credentials belonging to a particular user. While the app is still running, the original user lets a friend borrow the browser. The friend opens another tab, logs the original user out of the Service Provider, and then logs in as different user using the friend's account.

At this point - the app is still running as the original user a different tab. If the app's credentials expire, it could attempt an immediate request to refresh them - which could then return the credentials belonging to the 2nd user. Since this is a JS app - the data that belongs to the first user is already loaded, so the app could start co-mingling the data between the two users.

At Yahoo, we call this scenario  "crossing the streams" - and that's always a really bad thing.

This scenario could be really disastrous if the SP has a login CSRF vulnerability - meaning that an attacker can CSRF the victim's browser into logging in with the attacker's account. This vulnerability would result in the victim's data mixing with the Attacker.

One possible way to prevent this issue is for the client to pass the user's identifier (or access token/refresh token/etc) in the immediate request.

Allen

EHL