On Tue, Aug 3, 2010 at 1:28 PM, Yoav Nir <y...@checkpoint.com> wrote: > > 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.
Yes, definitely, thirdparty.com must be trusted, it is the client that the end user is authorizing. >> 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. True. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
