On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir <y...@checkpoint.com> wrote: > > On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote: > > Please provide an example of code that you would put to thirdparty.com and > that > > would not break the use cases. > > Take a look at the facebook APIs, in particular the cross-domain > communication schemes: > > http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication_Channel > > Please also provide an example of response from > > serviceprovider.com with an access token in it (wherever it is - as I > understand > > you want to put it to the Location header, but probably I'm wrong). > > HTTP/1.1 302 Moved Temporarily > > Location: http://www.thirdparty.com/rpc_relay.html#access_token=12345 > > rpc_relay.html is highly cached in the browser, so instead of > incurring hundreds of ms to fetch a file, the data lands in the > third-party.com javascript in under a millisecond. > > So if the browser works correctly (instead of what the python library does, > then thirdparty.com sees only "GET rpc_relay.html", while the javascript > also gets the "access_token=12345". > What I'm not getting is why this matters. Is this supposed to be about > security? It can't be any good at that, because the javascript is coming > from thirdparty.com. If the good people at thirdparty.com want to know the > access token, they can make their javascript send it to them. So what is > the purpose of this funky use of HTTP? Is the access token a secret? From > who?
Passing the access toke through the URL is insecure and prone to leaking. If in the query string then the access token my leak through: - log files, web server at thirdparty.com and any number of proxies - browser history - referer header Putting the access token into the fragment, and also using JavaScript to clean the URL as soon as the token is extracted, mitigates most of these issues. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
