Thanks, GeorgeP.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 / Googlejpanzer at google.com <mailto:jpanzer at google.com> / abstractioneer.org <http://www.abstractioneer.org/> / @jpanzerOn Fri, Oct 2, 2009 at 9:16 AM, George Fletcher <gffletch at aol.com <mailto:gffletch at aol.com>> 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. 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: 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-----Original Message----- From: George Fletcher [mailto:gffletch at aol.com <mailto:gffletch at aol.com>] Sent: Friday, October 02, 2009 5:04 AM To: oauth at ietf.org <mailto:oauth at ietf.org> Cc: Eran Hammer-Lahav; Brian Eaton Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) 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:Can you describe the actual use case? EHL-----Original Message----- From: oauth-bounces at ietf.org <mailto:oauth-bounces at ietf.org> [mailto:oauth-bounces at ietf.org <mailto:oauth-bounces at ietf.org>] OnBehalfOf Brian Eaton Sent: Thursday, October 01, 2009 9:01 PM To: George Fletcher Cc: oauth at ietf.org <mailto:oauth at ietf.org> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher <gffletch at aol.com <mailto:gffletch at aol.com>> wrote:One use case (I think I saw it mentioned somewhere else on thelist)wherewe've used the URI parameters is when we want the server to sign aURL andthen pass that signed value to the browser to load. This can bedonewith asimple 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... _______________________________________________ OAuth mailing list OAuth at ietf.org <mailto:OAuth at ietf.org> https://www.ietf.org/mailman/listinfo/oauth_______________________________________________ OAuth mailing list OAuth at ietf.org <mailto:OAuth at ietf.org> https://www.ietf.org/mailman/listinfo/oauth_______________________________________________ OAuth mailing list OAuth at ietf.org <mailto:OAuth at ietf.org> https://www.ietf.org/mailman/listinfo/oauth
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.