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 > -----Original Message----- > From: George Fletcher [mailto:gffletch at aol.com] > Sent: Friday, October 02, 2009 10:31 AM > To: oauth at ietf.org > Cc: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > > 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: > > 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/1k2j3h1oi823h123hk1j23ho182h31j2h3o18 > 2h3o12hi3o182h3o182h3 > > > > 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.