Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!)

From: George Fletcher <[email-masked]>
Date: Thu, 01 Oct 2009 22:52:18 -0400

Eran Hammer-Lahav wrote:
> * Many web platforms do not provide access to the wire HTTP request URI (either on the client or server side)
>
> requires more research but it also holds the key to much of the protocol design, namely:
>
> - The canonicalization of the HTTP request parameter and URI - this was done due to the fact that at the time, many popular web platforms did not provide easy access to the raw HTTP request URI and headers. If this is no longer the case, OAuth can be significantly simplified to remove the need to process the parameters and only treat the request URI.
>
> - The inclusion of multiple parameter transmission methods - this was done due to lack of access to the Authorization header in some clients and server environment. If this is no longer a requirement or if we come to the conclusion that HTTP caching requires that we use the header in all requests, the need to support parameters in places other than the header will also go away.
>
>   
One use case (I think I saw it mentioned somewhere else on the list) 
where we've used the URI parameters is when we want the server to sign a 
URL and then pass that signed value to the browser to load. This can be 
done with a simple 302 and the signed URL. Switching to just supporting 
the Authorization header will make this more difficult but probably not 
impossible.

Thanks,
George

---

From: Brian Eaton <[email-masked]>
Date: Thu, 1 Oct 2009 21:00:39 -0700

On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher <[email-masked]> wrote:
> One use case (I think I saw it mentioned somewhere else on the list) where
> we've used the URI parameters is when we want the server to sign a URL and
> then pass that signed value to the browser to load. This can be done with a
> simple 302 and the signed URL. Switching to just supporting the
> Authorization header will make this more difficult but probably not
> impossible.

Yep.  I've seen that done multiple places.

One more unexpected use of OAuth...

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Oct 2009 22:50:38 -0700

Can you describe the actual use case?

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Thursday, October 01, 2009 9:01 PM
> To: George Fletcher
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!)
> 
> where
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 2 Oct 2009 16:10:48 +1000

>>> URL and then pass that signed value to the browser to load.
>>> This can be done with a simple 302 and the signed URL.

> Can you describe the actual use case?

Amazon S3 (simple storage service) offer this feature.
You can store your private data in S3.
To access it you digitally-sign your HTTP requests (using HMAC) -- putting the signature in an HTTP Authorization header.
If you want to give another user (temporary) access to one piece of your data, you send them a signed URI for that data. They can now download the data. They never get your S3 credentials. They can access the data from a standard browser. The bulk data transfer can go straight from S3 to their browser, not via your computer.

I believe it is useful for buying content (movies, software...). Once you have paid you get the signed URI, it times-out shortly afterwards.

James Manger
[email-masked]
Identity and security team — Chief Technology Office — Telstra

---

From: George Fletcher <[email-masked]>
Date: Fri, 02 Oct 2009 08:03:42 -0400

In addition to the use case James described, we use this to enable 
single sign on from a client/desktop app into a browser session. The 
client signs the URL and then opens the browser with that URL. The 
backend validates the signature and access token and then establishes an 
authentication session for the user.

A variant of this case is where a partner uses a back-channel federation 
call to authenticate their user to the AOL authentication service. A 
successful response includes an access token and secret (the equivalent 
of) which the partner can then user to sign an URL when their user 
invokes an AOL service (again providing SSO).

Thanks,
George

P.S. Documentation on this signed API call can be found here: 
http://dev.aol.com/authentication_for_clients#client2web

P.P.S. While these APIs are not OAuth specifically, the patterns are 
needed for OAuth compliant APIs to be developed

Eran Hammer-Lahav wrote:
>>> we've used the URI parameters is when we want the server to sign a
>>>       
>> URL and
>>     
>>> then pass that signed value to the browser to load. This can be done
>>>       
>> with a
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Oct 2009 08:12:05 -0700

Thanks James, George.

If we are going to support sending authentication credentials in the URI query, what are the requirements to make sure it works well with proxies and caches? What headers do we need to require the server to return to make sure it doesn't get cached? Do we need to require a nonce value for all signature methods to ensure making the request more unique and less likely to repeat?

In these two use cases, is there a reason for the URI to be used more than once? Can we simplify the credentials passed via the URI query to provide adequate security but without the need for a long and ugly URI with multiple oauth_ prefixed parameters?

These are valid use cases and something we need to worry about to get this new protocol deployed where other proprietary ones are deployed. But I am not that concerned about the use case mentioned earlier of 'just making it easier to send requests'. So if we support query parameters but after some processing of the parameters to make the URI simpler, that would be acceptable to me.

EHL

> From: George Fletcher [mailto:[email-masked]]
> Sent: Friday, October 02, 2009 5:04 AM
> To: [email-masked]
> Cc: Eran Hammer-Lahav; Brian Eaton

---

From: George Fletcher <[email-masked]>
Date: Fri, 02 Oct 2009 12:16:15 -0400

I would expect that in the Amazon case being able to reuse the URL would 
be beneficial, but I'm not really familiar with that use case.

For the SSO use cases, the desire is to prevent replay and make the URL 
one time use only. We do set cookies during the redirect process so a 
cache replaying those cookies could be problematic. There are a number 
of cache control directives that can be used for correctly implemented 
proxies.

A couple reasonable links on the topic

[1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html
[2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=-1
[3] http://code.google.com/speed/page-speed/docs/caching.html

However, I think this issue is bigger than just requests with URL 
parameters. If I access a rest resource 
http://photos.example.com/alice/album/vacation along with it's 
Authorization header, if this request goes through a proxy, the proxy 
will mostly likely ignore the Authorization header. Hence the next time 
that static URL is requested, the contents is returned. The same cache 
control headers the server needs to send for these specific use cases 
will apply to the general case as well. I'm a little behind in the lists 
servs. Has this issue already been solved for the general case using the 
Authorization header?

Thanks,
George

Eran Hammer-Lahav wrote:
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>         
>> Behalf
>>     
>>>> Of Brian Eaton
>>>>> One use case (I think I saw it mentioned somewhere else on the
>>>>>           
>> list)
>>     
>>>> where
>>>>
>>>>         
>>>>> then pass that signed value to the browser to load. This can be
>>>>>           
>> done
>>     
>>>> with a
>>>>
>>>>

---

From: Brian Eaton <[email-masked]>
Date: Fri, 2 Oct 2009 09:21:29 -0700

> If we are going to support sending authentication credentials in the URI query, what are the
> requirements to make sure it works well with proxies and caches? What headers do we
> need to require the server to return to make sure it doesn't get cached?

AFAICT, cache control headers and OAuth are completely orthogonal
questions.  Any web server returning any type of personal/private data
must return cache-control headers.  That's true whether the
authentication is based on secret URLs, or cookies, or basic auth
headers, or OAuth.

Cheers,
Brian

---

From: John Panzer <[email-masked]>
Date: Fri, 2 Oct 2009 09:50:36 -0700

IANACI (I Am Not A Cache Implementor) but I believe that Authorization:
headers cause most default-configured caches to bypass the cache.
 Aggressive caches can defeat this of course.  Caches should pay attention
to Vary: as well.
--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Fri, Oct 2, 2009 at 9:16 AM, George Fletcher <[email-masked]> wrote:

> I would expect that in the Amazon case being able to reuse the URL would be
> beneficial, but I'm not really familiar with that use case.
>
> For the SSO use cases, the desire is to prevent replay and make the URL one
> time use only. We do set cookies during the redirect process so a cache
> replaying those cookies could be problematic. There are a number of cache
> control directives that can be used for correctly implemented proxies.
>
> Authorization header, if this request goes through a proxy, the proxy will
> mostly likely ignore the Authorization header. Hence the next time that
> static URL is requested, the contents is returned. The same cache control
> headers the server needs to send for these specific use cases will apply to
> the general case as well. I'm a little behind in the lists servs. Has this
> issue already been solved for the general case using the Authorization
> header?
>
> Thanks,
> George
>
>
>
>
> Eran Hammer-Lahav wrote:
>
>> Thanks James, George.
>>
>> If we are going to support sending authentication credentials in the URI
>> query, what are the requirements to make sure it works well with proxies and
>> caches? What headers do we need to require the server to return to make sure
>> it doesn't get cached? Do we need to require a nonce value for all signature
>> methods to ensure making the request more unique and less likely to repeat?
>>
>> In these two use cases, is there a reason for the URI to be used more than
>> once? Can we simplify the credentials passed via the URI query to provide
>> adequate security but without the need for a long and ugly URI with multiple
>> oauth_ prefixed parameters?
>>
>> These are valid use cases and something we need to worry about to get this
>> new protocol deployed where other proprietary ones are deployed. But I am
>> not that concerned about the use case mentioned earlier of 'just making it
>> easier to send requests'. So if we support query parameters but after some
>> processing of the parameters to make the URI simpler, that would be
>> acceptable to me.
>>
>> EHL
>>
>>
>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 02 Oct 2009 13:18:38 -0400

Agreed. I think the issue isn't "well behaved" caches because there are 
lots of ways to solve this (e.g. cache-control: private, expires: 0, 
vary (as you mentioned), etc). I believe the concern is the "aggressive 
caches". I agree with Brian that the issue of proxies and caching is 
orthogonal to the issue of URL parameters.

Thanks,
George

P.S. It also used to be that the presence of a '?' in a URL caused most 
well-behaved caches to bypass the cache as well. We had that rule it our 
caches for a very long time:)

John Panzer wrote:
> IANACI (I Am Not A Cache Implementor) but I believe that 
> Authorization: headers cause most default-configured caches to bypass 
> the cache.  Aggressive caches can defeat this of course.  Caches 
> should pay attention to Vary: as well.
> --
> John Panzer / Google
> [email-masked] <mailto:[email-masked]> / abstractioneer.org 
> <http://www.abstractioneer.org/> / @jpanzer
>
>
>
> On Fri, Oct 2, 2009 at 9:16 AM, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I would expect that in the Amazon case being able to reuse the URL
>     would be beneficial, but I'm not really familiar with that use case.
>
>     For the SSO use cases, the desire is to prevent replay and make
>     the URL one time use only. We do set cookies during the redirect
>     process so a cache replaying those cookies could be problematic.
>     There are a number of cache control directives that can be used
>     for correctly implemented proxies.
>
>     Authorization header, if this request goes through a proxy, the
>     proxy will mostly likely ignore the Authorization header. Hence
>     the next time that static URL is requested, the contents is
>     returned. The same cache control headers the server needs to send
>     for these specific use cases will apply to the general case as
>     well. I'm a little behind in the lists servs. Has this issue
>     already been solved for the general case using the Authorization
>     header?
>
>     Thanks,
>     George
>
>
>
>
>     Eran Hammer-Lahav wrote:
>
>         Thanks James, George.
>
>         If we are going to support sending authentication credentials
>         in the URI query, what are the requirements to make sure it
>         works well with proxies and caches? What headers do we need to
>         require the server to return to make sure it doesn't get
>         cached? Do we need to require a nonce value for all signature
>         In these two use cases, is there a reason for the URI to be
>         used more than once? Can we simplify the credentials passed
>         via the URI query to provide adequate security but without the
>         need for a long and ugly URI with multiple oauth_ prefixed
>         parameters?
>
>         These are valid use cases and something we need to worry about
>         to get this new protocol deployed where other proprietary ones
>         are deployed. But I am not that concerned about the use case
>         mentioned earlier of 'just making it easier to send requests'.
>         So if we support query parameters but after some processing of
>         the parameters to make the URI simpler, that would be
>         acceptable to me.
>
>         EHL
>
>          
>
>             From: George Fletcher [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             To: [email-masked] <mailto:[email-masked]>
>             backend validates the signature and access token and then
>             establishes
>             an
>                     From: [email-masked]
>                     <mailto:[email-masked]>
>                     [mailto:[email-masked]
>                     <mailto:[email-masked]>] On
>                            
>
>             Behalf
>                
>
>                     Of Brian Eaton
>                     Cc: [email-masked] <mailto:[email-masked]>
>                     On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher
>                     <[email-masked] <mailto:[email-masked]>>
>                     wrote:
>
>                            
>
>                     [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Oct 2009 10:20:46 -0700

Actually, I am going to take this back.

This is not really a valid reason to support authentication parameters in the query. In this scenario, the resource owner is able to make an authenticated request using the auth headers. That request produces a special URI which can be shared, bypassing the access controls. Why does this needs to be covered by OAuth? What prevents any server from issuing a time-limited/restricted/single-use/etc URI using long token such as:

http://example.com/resource/share/1k2j3h1oi823h123hk1j23ho182h31j2h3o182h3o12hi3o182h3o182h3

I just don't see any reason why this is lesser than producing a URI that uses OAuth parameters. Whatever the server needs can be either encoded into this long token or maintained in a database.

So back to no real use case for query parameters support.

EHL

> Sent: Friday, October 02, 2009 9:16 AM
> To: [email-masked]
> Cc: Eran Hammer-Lahav
> would
> > If we are going to support sending authentication credentials in the
> URI query, what are the requirements to make sure it works well with
> proxies and caches? What headers do we need to require the server to
> return to make sure it doesn't get cached? Do we need to require a
> nonce value for all signature methods to ensure making the request more
> unique and less likely to repeat?
> >
> > In these two use cases, is there a reason for the URI to be used more
> than once? Can we simplify the credentials passed via the URI query to
> provide adequate security but without the need for a long and ugly URI
> with multiple oauth_ prefixed parameters?
> 
> >
> > These are valid use cases and something we need to worry about to get
> this new protocol deployed where other proprietary ones are deployed.
> But I am not that concerned about the use case mentioned earlier of
> 'just making it easier to send requests'. So if we support query
> parameters but after some processing of the parameters to make the URI
> simpler, that would be acceptable to me.
> >
> > EHL
> >
> >

---

From: Brian Eaton <[email-masked]>
Date: Fri, 2 Oct 2009 10:25:59 -0700

On Fri, Oct 2, 2009 at 10:20 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> Why does this needs to be covered by OAuth? What prevents any server from issuing
> a time-limited/restricted/single-use/etc URI using long token such as:
>
> I just don't see any reason why this is lesser than producing a URI that uses OAuth parameters.
> Whatever the server needs can be either encoded into this long token or maintained in a database.

I'd bet that people will keep using the OAuth 1.0 URL signing scheme
for this purpose.  It works pretty well as-is.

URL signing doesn't seem to apply to the core OAuth use cases around
delegation and client-to-server authentication.

Cheers,
Brian

---

From: George Fletcher <[email-masked]>
Date: Fri, 02 Oct 2009 13:30:56 -0400

This is possible but it gets complicated. If server A (the one issuing 
the long encrypted opaque token) is separate (meaning not from the same 
company) from server B (the server receiving and validating the token) 
then both server A and Server B have to agree on the format of the token 
and the mechanism for "encrypting" or "signing" it.

Since OAuth provides a way to secure requests via signing, this becomes 
a very easy way to support servers A and B being from multiple companies 
(or whatever). For sure, the partners could agree to take the string 
that would be the value of the Authorization header, base64 it and add 
it to the URL.

Maybe this could be the simplifying mechanism for adding OAuth to URLs. 
Just define an oauth_authz parameter that is optional and contains the 
base64 encoded version of the Authorization header. Simple to process 
and easy to implement.

Thanks,
George

Eran Hammer-Lahav wrote:
>>>> successful response includes an access token and secret (the
>>>>         
>> equivalent
>>     
>>>>>>> we've used the URI parameters is when we want the server to sign
>>>>>>>               
>> a
>>     
>>>>>>>               
>>>>>> URL and
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Authorization header will make this more difficult but probably
>>>>>>>               
>> not
>>     
>>>>>>> impossible.
>>>>>>>
>>>>>>>
>>>>>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Oct 2009 10:44:54 -0700

I can live with something like that. The problem will be that it will require normalizing the request URI to remove the OAuth parameter before validating the signature. But this is completely on the server so I don't mind it.

I'll include something like this in the upcoming revision (pending more feedback).

As for sending form-encoded auth parameters, no one has argued to keep that so I think it is save to drop it completely.

EHL

> Sent: Friday, October 02, 2009 10:31 AM
> To: [email-masked]
> Cc: Eran Hammer-Lahav
> > This is not really a valid reason to support authentication
> parameters in the query. In this scenario, the resource owner is able
> to make an authenticated request using the auth headers. That request
> produces a special URI which can be shared, bypassing the access
> controls. Why does this needs to be covered by OAuth? What prevents any
> server from issuing a time-limited/restricted/single-use/etc URI using
> long token such as:
> >
> >
> > I just don't see any reason why this is lesser than producing a URI
> that uses OAuth parameters. Whatever the server needs can be either
> encoded into this long token or maintained in a database.
> >
> proxy
> <[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Fri, 02 Oct 2009 14:06:24 -0400

> As for sending form-encoded auth parameters, no one has argued to keep that so I think it is save to drop it completely.
I actually had a use case for this (as an idea) but it didn't go 
anywhere. Basically it was leveraging the signing mechanism as a binding 
for SAML messages. Logically it would be similar to SAML Simple Sign but 
for server-to-server calls.

However, if we add the body-hash support then I think that covers POST'd 
content and it can be in any format.

Thanks,
George
>>>> For the SSO use cases, the desire is to prevent replay and make the
>>>>         
>> URL
>>     
>>>> one time use only. We do set cookies during the redirect process so
>>>>         
>> a
>>     
>>>> cache replaying those cookies could be problematic. There are a
>>>>         
>> number
>>     
>>>> of cache control directives that can be used for correctly
>>>>         
>> implemented
>>     
>>>> proxies.
>>>>
>>>> will mostly likely ignore the Authorization header. Hence the next
>>>>         
>> time
>>     
>>>> that static URL is requested, the contents is returned. The same
>>>>         
>> cache
>>     
>>>> control headers the server needs to send for these specific use
>>>>         
>> cases
>>     
>>>>> If we are going to support sending authentication credentials in
>>>>>           
>> the
>>     
>>>> nonce value for all signature methods to ensure making the request
>>>>         
>> more
>>     
>>>>> In these two use cases, is there a reason for the URI to be used
>>>>>           
>> more
>>     
>>>> than once? Can we simplify the credentials passed via the URI query
>>>>         
>> to
>>     
>>>> provide adequate security but without the need for a long and ugly
>>>>         
>> URI
>>     
>>>>> These are valid use cases and something we need to worry about to
>>>>>           
>> get
>>     
>>>> this new protocol deployed where other proprietary ones are
>>>>         
>> deployed.
>>     
>>>> parameters but after some processing of the parameters to make the
>>>>         
>> URI
>>     
>>>>>> single sign on from a client/desktop app into a browser session.
>>>>>>             
>> The
>>     
>>>>>> call to authenticate their user to the AOL authentication service.
>>>>>>             
>> A
>>     
>>>>>> P.P.S. While these APIs are not OAuth specifically, the patterns
>>>>>>             
>> are
>>     
>>>>>>>>> we've used the URI parameters is when we want the server to
>>>>>>>>>                   
>> sign
>>     
>>>> a
>>>>
>>>>         
>>>>>>>> URL and
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Oct 2009 11:26:19 -0700

The key here the transmission of auth parameters, not singing bodies.

EHL

> Sent: Friday, October 02, 2009 11:06 AM
> To: [email-masked]
> Cc: Eran Hammer-Lahav
> > I can live with something like that. The problem will be that it will
> require normalizing the request URI to remove the OAuth parameter
> before validating the signature. But this is completely on the server
> so I don't mind it.
> >
> > As for sending form-encoded auth parameters, no one has argued to
> keep that so I think it is save to drop it completely.
> >
> >
> >>>> servs. Has this issue already been solved for the general case
> using
> >>>> the
> >>>> Authorization header?
> >>>>
> >>>> Thanks,
> >>>> George
> >>>>
> >>>>
> >>>>
> >>>> Eran Hammer-Lahav wrote:
> >>>>
> >>>>
> >>>>> Thanks James, George.
> >>>>>