Yoav - You can take a look at this as a starting point:
http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsiderations/OAuthWRAP2.0SecurityConsiderations.pdf On Tue, Aug 3, 2010 at 1:38 PM, Marius Scurtescu <mscurte...@google.com> wrote: > 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
