No exactly… Consensus is on:
1. Code in query 2. Token in fragment 3. Code and Token in fragment There was some interest (but no consensus) for: 4. Code in query and Token in fragment The spec always had #1 (web server) and #2 (user agent). Draft -10 has #4 but based on feedback from Brian and Naitik, this is inefficient and #3 is a better approach. I am going to have -11 reflect #1, #2, and #3 and drop #4. EHL From: [email protected] [mailto:[email protected]] On Behalf Of Torsten Lodderstedt Sent: Wednesday, August 11, 2010 10:36 AM To: Torsten Lodderstedt Cc: Naitik Shah; Oleg Gryb; OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query From what has been discussed in this thread (and other discussions before), I see the need for the following variants: - code in URI (Web App.) - token in fragment (JS client app) - code in fragment (installed app) - code in URI + token in fragment (Web App. with JS Client?) Any comments? regards, Torsten. Am 10.08.2010 um 19:57 schrieb Torsten Lodderstedt <[email protected]<mailto:[email protected]>>: Thank you for the explanation. I now understand that the fragment is used for efficiently passing token or code on the client side. What I still don't understand is why a client would need both at once (url 1)? Have you such applications in production? regards, Torsten. Am 10.08.2010 um 19:23 schrieb Luke Shepard <[email protected]<mailto:[email protected]>>: 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 <[email protected]<mailto:[email protected]>> Can someone pls. explain why code and token should both be returned in the fragment? regards, Torsten. _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
