Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 2 Sep 2010 09:53:26 -0700

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-masked] [mailto:[email-masked]] 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-masked]<mailto:[email-masked]>>:
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-masked]<mailto:[email-masked]>>:
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-masked]<mailto:[email-masked]>>
Can someone pls. explain why code and token should both be returned in the fragment?

regards,
Torsten.

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth