Re: [OAUTH-WG] OAuth and HTTP caching

That works -- provided OAuth is completely proof against replay attacks.

However, are new headers really necessary? Reading in various places  
about this issue, it seems like a common workaround is to use  
mod_rewrite to expose the authorization header in the environment; e.g.,

RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

Isn't that enough to get the 80% case of those who have trouble with  
getting direct access? Specifying two different headers to be used on  
the wire will lead people to always use the more conservative one (X- 
whatever, blech) and thereby lead us directly back into the situation  
Eran's concerned about (intermediaries not realising that this is  
protected content). The workaround for that will be having the header  
duplicated, with both names (double blech).

Cheers,


On 23/09/2009, at 1:46 AM, John Panzer wrote:

> Inline...
>
> On Tuesday, September 22, 2009, Mark Nottingham <mnot@mnot.net> wrote:
>>
>> On 22/09/2009, at 7:56 AM, John Panzer wrote:
>>
>>
>> On the server side, one of the concerns in the past has been  
>> security in shared hosting systems where e.g., basic auth data  
>> should be handled by a secure container (Apache) and not passed on  
>> in raw form to hosted CGI scripts.  So some of this comes back to  
>> what minimum level of hosting should be targeted by the  
>> specification -- and how much it should bend over backwards to deal  
>> with "challenged" environments.
>>
>>
>> That's a good discussion to have.
>>
>>
>> My $.02 is that we should follow the HTTP spec (Authorization: and  
>> WWW-Authenticate:) and take a minimum distance path to route around  
>> limited environments if necessary (X-Authorization: and X-WWW- 
>> Authenticate:, with exactly the same content, would be my proposal).
>>
>>
>> Ugh. By allowing other resources on the same server to see  
>> authentication credentials, wouldn't that just re-open these attacks?
>>
>>
>
> 1. Oauth, at least when accessing protected resources, is designed to
> be used over insecure connections, so the password sniffing attacks
> don't apply.
>
> 2. The alternative on the table is to pass these as URL params, which
> are more sniffable and also makes the web cry.
>
>>
>>
>> --
>> John Panzer / Google
>> jpanzer@google.com / abstractioneer.org / @jpanzer
>>
>>
>>
>> On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav <eran@hueniverse.com 
>> > wrote:
>> As currently written, OAuth use of the HTTP authentication headers  
>> is optional at best.
>>
>> The reason for that was based on concerns that some platforms do  
>> not provide access to the HTTP header in either the request or the  
>> reply. However, this might have significant ramifications on  
>> caching and other parts of HTTP where an indication of an  
>> authenticate interaction is needed.
>>
>> Before the OAuth WG spends any time on discussing the various  
>> methods of sending authentication parameters, I would like to find  
>> out if using the authentication headers is more of a requirement  
>> for such a protocol.
>>
>> EHL
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>
> -- 
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @jpanzer


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 23 September 2009 04:04:10 UTC