Hey Oleg, a server based "safer" version of the user agent flow is the web server flow. It doesn't pass the access token via the fragment or via any means without SSL.
On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb <oleg_g...@yahoo.com> wrote: > Luke, > > Thanks for answering. Sorry, for been paranoid, but I think that you'll have > more qs in regards of your frame-based-cross-domain-secret-sharing solution. > > The thing is that each time when a web app with sensitive info can be run in > a frame, security people would advice to break that > frame-reads-other-frame-data logic, because it can lead to violation of same > origin policy. > > I think Torsten's suggestion is correct: somebody would need to "threat > model" the current UA flow. > > Alternatively, you might want to consider creating yet another "safer UA > flow" where access token will not be passed in a URL. It might require using > dynamic pages generated by a server, but if somebody wants to implement a > more secure solution, they'll at least have a choice. > > > > > From: Luke Shepard <lshep...@facebook.com> > To: Oleg Gryb <o...@gryb.info> > Cc: Torsten Lodderstedt <tors...@lodderstedt.net>; David Recordon > <record...@gmail.com>; Naitik Shah <nai...@facebook.com>; OAuth WG > <oauth@ietf.org> > Sent: Tue, August 10, 2010 10:23:56 AM > Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query > > Here are the possible URLs: > http://static.facebook.com/connect/xd_proxy.php#code=10alkji&access_token=lzipa3p > http://static.facebook.com/connect/xd_proxy.php?code=10alkji#access_token=lzipa3p > Those who already use this flow in production (including Google, Facebook, > Twitter, and others) typically work like this: > - Parent frame initiates the transaction by spawning a popup or an iframe > - Response comes back to a static relay file (like the xd_proxy.php above) > - The relay interprets the URL, parses out arguments, and hands them to the > parent frame > - Parent frame then does what it wants. this could be making an API call via > JSONP, handing info to the server via Ajax, or something else. > Because the relay file is static, it isn't going to interpret the code > regardless, even if it is sent in the query parameter. So since the client > will handle it anyway, the fragment is better for two reasons: > 1/ Less code for the JS to just pull it out of the fragment > 2/ More efficient, as the relay file can be cached on the client. If you > include a code then you degrade performance because it busts the cache every > time. > > On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote: > > I was trying to understand that too (see "Is user agent profile secure" > thread). The answers that I've got were: > > 1. It's already coded this way. > 2. It's the most efficient way of doing that, because that relay.html page > is static and can be cached by a browser. > > None of the answers above looks very convincing to me, but that's where UA > is now. > > From: Torsten Lodderstedt <tors...@lodderstedt.net> > > Can someone pls. explain why code and token should both be returned in the > fragment? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
