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 > -----Original Message----- > From: George Fletcher [mailto:gffletch at aol.com] > Sent: Friday, October 02, 2009 9:16 AM > To: oauth at ietf.org > Cc: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > > 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] > >> Sent: Friday, October 02, 2009 5:04 AM > >> To: 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] On > >>>> > >> Behalf > >> > >>>> Of Brian Eaton > >>>> Sent: Thursday, October 01, 2009 9:01 PM > >>>> To: George Fletcher > >>>> Cc: 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> > >>>> 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... > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth at ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> > >>> > > _______________________________________________ > > OAuth mailing list > > 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.