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

From: David Recordon <[email-masked]>
Date: Mon, 9 Aug 2010 11:32:53 -0700

The thread wondered a bit but Brian's summary here seems to be what most
people were advocating for. Is there enough consensus to have Draft 11
reflect it?

Thanks,
--David

On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton <[email-masked]> wrote:

> I can't parse this diagam, but here's my take:
>
> - web server flow should always return just a code.
>   parameter always goes in the query string
>   it would be sort of reasonable to have the code exchange return
> just an access token, instead of a refresh token and an access token.
> Or a refresh token with a shorter lifetime than indefinite.
>
> - user-agent flow can reasonably return either just a token, or a
> token and a code
>   both parameters always go in the fragment, to avoid busting the browser
> cache
>   same comments about lifetime of refresh tokens...
>
> Cheers,
> Brian
>
> On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav <[email-masked]>
> wrote:
> > Please answer this based on actual use cases. When returning parameters
> > using the redirection URI call, which of these combinations make sense?
> >
> >         | Code | Token | Code & Token
> > ---------+------+-------+--------------
> > Fragment |  a   |   1   |   3
> > Query    |  2   |   b   |   c
> > Split*   | n/a  |  n/a  |   d
> >
> > * token in fragment, code in query
> >
> > Known use cases:
> >
> > 1 - current user-agent flow
> > 2 - current web-server flow
> > 3 - as described by Brian and Naitik
> >
> > Do you need any of these?
> >
> > a -
> > b -
> > c -
> > d - current -10 code-and-token proposal
> >
> > EHL
> >
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Luke Shepard <[email-masked]>
Date: Mon, 9 Aug 2010 19:59:57 +0000

I like Brian's solution.

On Aug 9, 2010, at 11:32 AM, David Recordon wrote:

The thread wondered a bit but Brian's summary here seems to be what most people were advocating for. Is there enough consensus to have Draft 11 reflect it?

Thanks,
--David

On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton <[email-masked]<mailto:[email-masked]>> wrote:
I can't parse this diagam, but here's my take:

- user-agent flow can reasonably return either just a token, or a
token and a code
  both parameters always go in the fragment, to avoid busting the browser cache
  same comments about lifetime of refresh tokens...

Cheers,
Brian

On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Naitik Shah <[email-masked]>
Date: Mon, 9 Aug 2010 20:00:22 +0000

me too

On Aug 9, 2010, at 12:59 PM, Luke Shepard wrote:

>> On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav <[email-masked]> wrote:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 10 Aug 2010 14:20:03 +0200

Can someone pls. explain why code and token should both be returned in the fragment?

regards,
Torsten.

---

From: Oleg Gryb <[email-masked]>
Date: Tue, 10 Aug 2010 09:35:05 -0700 (PDT)

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]>

Can someone pls. explain why code and token should both be returned in the 
fragment?

---

From: Luke Shepard <[email-masked]>
Date: Tue, 10 Aug 2010 17:23:56 +0000

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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 10 Aug 2010 19:51:11 +0200

Thank you for the explanation. I no

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 10 Aug 2010 19:57:28 +0200

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.

---

From: Oleg Gryb <[email-masked]>
Date: Tue, 10 Aug 2010 11:00:19 -0700 (PDT)

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 <[email-masked]>
>To: Oleg Gryb <[email-masked]>
>Cc: Torsten Lodderstedt <[email-masked]>; David Recordon 
><[email-masked]>; Naitik Shah <[email-masked]>; OAuth WG 
><[email-masked]>
>Sent: Tue, August 10, 2010 10:23:56 AM
>Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query
>
>
>Those who already use this flow in production (including Google, Facebook, 
>Twitter, and others) typically work like this:
>
>
>- 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:
>
>
>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.
>
>
>
>

---

From: David Recordon <[email-masked]>
Date: Tue, 10 Aug 2010 13:19:04 -0700

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 <[email-masked]> wrote:
> 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.
>
>
>
>
> 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:
> 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.
>
> 2. It's the most efficient way of doing that, because that relay.html page
> is static and can be cached by a browser.
>

---

From: "Gryb, Oleg" <[email-masked]>
Date: Tue, 10 Aug 2010 13:21:52 -0700

Yes, but you'll need a web server client for that. I'm saying that UA profile can be POST based too.

If you want, I can write an example of both client and server side code to explain what I mean.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 11 Aug 2010 19:36:20 +0200

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.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 11 Aug 2010 11:03:12 -0700

> frame-reads-other-frame-data logic, because it can lead to violation of same

This is incorrect.  The security of this flow is based entirely on the
same-origin policy.  Same-origin provides the basic authentication of
the destination of the access tokens.

Note that both the web-server and the user-agent flows are entirely
about passing information to third-party web sites, so suggesting that
these flows should not pass information across domains is not really
helpful. =)

> Yes, but you'll need a web server client for that. I'm saying that UA profile can

(a) The POST would bust the browser cache.
(b) Javascript can't read POST bodies.  (At least not to my knowledge.
 If you know of client-side code that can do this, I'm interested.)

If we were willing to accept the performance penalty of busting the
browser-cache, we would use the web-server flow.

---

From: Oleg Gryb <[email-masked]>
Date: Thu, 12 Aug 2010 08:26:58 -0700 (PDT)

----- Original Message ----
> From: Brian Eaton <[email-masked]>
> Cc: Naitik Shah <[email-masked]>; OAuth WG <[email-masked]>
> Sent: Wed, August 11, 2010 11:03:12 AM
> same-origin policy.  

It is not: you get an access token from authz server and want to share it with 
thirdparty.com domain, which is in a different domain. You do it through frames 
running in a browser. Do a threat modeling as others suggested here. Why the 
access token needs to be shared with thirdparty.com is still not clear.

> these flows should  not pass information across domains is not really

There are two kinds of information here: thirdparty.com state (e.g. list of 
selected photos on Facebook) and access token, which is really a printing.com 
secret. If you store access token in a printing.com cookie you don't need to 
share it with thirdparty.com.

> >  Yes, but you'll need a web server client for that. I'm saying that UA 
>profile  can
> > be POST based too.
> 

No, it can't and I never said it could. Busting the browser cache by writing a 
server side logic doesn't look like a big issue or performance lost to me. You 
could aqcwire access token once, persist it (e.g. through a cookie in 
printing.com domain) and reuse until it's expired.

> browser-cache, we would use the web-server  flow.

I'm still struggling to undertand what you're trying to achieve with UA profile. 
If it's getting rid of web server client, you didn't aachieve it, because you 
still have thridparty.com, which is actually a web server client.

Here are some qs to the existing spec (v.10) related to that:

   "The user-agent profile is suitable for client applications residing
   in a user-agent, typically implemented in a browser using a scripting
   language such as JavaScript"Client application (JavaScript) resides and is 
implemented on thrirdparty.com. Browser only executes it, so you actually do 
have a web server client, it just you don't want to use server side code and 
server side objects, right? If this is the case, why don't you say it 
explicitly?

"These clients cannot keep client
   secrets confidential"What is wrong with cookies? 

I think, in your UA flow you'll also need to reflect:

1. thirdparty.com and it's role.
2. the cross-domain secret sharing logic that we've discussed here and why you 
need it.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 12 Aug 2010 09:25:37 -0700

Hi Oleg -

"There are two kinds of information here: thirdparty.com state (e.g. list of
selected photos on Facebook) and access token, which is really a
printing.com
secret. If you store access token in a printing.com cookie you don't need to
share it with thirdparty.com."

The goal of the flow is for third-party.com to access printing.com.  That is
what the user wants to have happen, and the service provider wants to allow
it.

Cheers,
Brian

On Thu, Aug 12, 2010 at 8:26 AM, Oleg Gryb <[email-masked]> wrote:

> > > The  thing is that each time when a web app with sensitive info can be
> run
> in
> > >  frame-reads-other-frame-data logic, because it can lead to violation
> of
> >same
> > > origin policy.
> >