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 <oleg_g...@yahoo.com> wrote: > > > > > ----- Original Message ---- > > From: Brian Eaton <bea...@google.com> > > To: Oleg Gryb <o...@gryb.info> > > Cc: Naitik Shah <nai...@facebook.com>; OAuth WG <oauth@ietf.org> > > Sent: Wed, August 11, 2010 11:03:12 AM > > Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query > > > > On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb <oleg_g...@yahoo.com> 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. > > > > This is incorrect. The security of this flow is based entirely on the > > 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. > > > 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. =) > > 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. > > > > (a) The POST would bust the browser cache. > > (b) Javascript can't read POST bodies. (At least not to my knowledge. > > 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. > > > If we were willing to accept the performance penalty of busting the > > 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. > > > _______________________________________________ > > 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
