On Aug 3, 2010, at 11:18 PM, Marius Scurtescu wrote: > 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.
Insecure against what? Prone to leaking of what to whom? > 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 You're counting a lot on the javascript. That Javascript is coming from thirdparty.com. So we have to assume both trustworthiness and competence of the people in thirdparty. > > 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. I think a security considerations section (different for each profile) is desperately needed. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
