On Sun, Jun 13, 2010 at 5:55 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> To be clear, you are +1 on using only JSON for server responses on the > token endpoint? > Yes, +1 on JSON responses for token endpoint. > > > EHL > > > > *From:* Evan Gilbert [mailto:uid...@google.com] > *Sent:* Sunday, June 13, 2010 11:20 AM > *To:* Eran Hammer-Lahav > *Cc:* Robert Sayre; OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] Proposal for single JSON response format > > > > > > On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > Using JSON in the end-user authorization endpoint response is still > something we need to discuss. In the web server flow, it makes more sense to > use form-encoded because the URI is processed by a typical query processor > (automatic in every web server). In the fragment, it is a question of > preference, and I was told that there are many benefits to using JSON. I > think Facebook uses JSON in such a way. > > > > However, there is still value in using JSON across all server responses > because it allows returning the same structured data. > > > > Can you explain the XSS hole from parsing a random JSON string? > > > > Naive processor calls: > > var href = document.location.href; > > var jsonBlob = href.substring(href.indexOf('#'), href.length) > > var userData = eval(jsonBlob); > > > > This code would allow executing arbitrary code by sending a user a link, > which could, for example, steal your cookies on a site. > > > > The fix is just a really complicated RegEx match - here is sample > code<http://www.google.com/codesearch/p?hl=en#MSH8LMSqi38/trunk/features/core/json.js&q=parse%20gadgets.json%20shindig%20package:%22http://svn.apache.org/repos/asf/incubator/shindig/%22&sa=N&cd=1&ct=rc&l=141>from > Shindig that does this correctly - but I would worry that implementers > would do the simple thing and just eval the JSON. It also seems like a sign > of a design issue if the spec requires this regex. > > > > > > If all server responses are JSON, why does the client have to do > form-decoding? > > > > Redirect_uri needs to be put into a URL somehow, and the URL may have other > query parameters or other content in the fragment. I'm making the assumption > that we would put this into a query parameter - otherwise we need to specify > ourselves how to encode the JSON to be URL-safe and not conflict with other > parameters. > > > > What simple model? Format isn’t a model. > > Sorry, the statement about "simple model" wasn't that helpful without > context. Here's the context: > > - We currently have listed 4 named parameters that may be returned. > - Using query parameters is an obvious / clear way to return these > parameters when encoded in a URL (in the fragment, a common practice is to > use the same query parameter format, but after the hash). > - All modern coding environments I know of can pull out simple key / > value pairs encoded in URL parameters. Issues I've heard with URL > parameters > are all around: > > > 1. Canonicalization of parameters for signing, and > 2. Parameters that are not simple key/value pairs (i.e. how do you > encode a linefeed. > > > - The data returned on a URL should probably *not* be the same as what > you would return on the server. This is because the data is untrusted - > evildoers can construct a URL with the wrong JSON data. > > So my preference would be to leave the redirect URI as simple key/value > pairs and actively try to discourage adding structured / complex content. We > can use a followup call to the AS with the access token on the server side > for complex data, and JSON is the right response format for this followup > call. > > > > EHL > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Evan Gilbert > *Sent:* Sunday, June 13, 2010 2:47 AM > *To:* Robert Sayre > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Proposal for single JSON response format > > > > -1 > > > > I disagree very strongly with this approach if I'm understanding > correctly. Let me paraphrase to make sure I understand: > > > > All responses, even those encoded in a browser URL redirect back from the > AS (redirect with verification code in the web server flow and the redirect > with token in the user-agent flow) will be JSON > > > This means that we will have a URL-encoded JSON blob as a form parameter > (as it has to play nicely with existing URL parameters). So the response > back in the web server flow would be: > > https://client.com/receiveVerificationCode?existingParam=value&oauth2=%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'%7D > > and the response back in the user-agent flow would be > > https://client.com/page?existingParam=value&oauth2=%7Baccess_token%3A+'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'randomstatedata'%7D > > > > Reasons why this is of concern: > > - Requires clients to do URL decoding *and* JSON decoding > > - Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) = XSS > hole) > > - Breaks the simple model we've been creating in these flows. > > > > Evan > > > > On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre <say...@gmail.com> wrote: > > +1 > > > On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <n...@daaku.org> wrote: > > +1 > > > > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard <lshep...@facebook.com> > wrote: > >> > >> +1 > >> > >> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: > >> > >> > +1 > >> > > >> > -- > >> > James Manger > >> > > >> > ---------- > >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > Behalf > >> > Of Eran Hammer-Lahav > >> > Sent: Friday, 11 June 2010 6:29 AM > >> > To: OAuth WG (oauth@ietf.org) > >> > Subject: [OAUTH-WG] Proposal for single JSON response format > >> > > >> > - Support a single response format (including in the user-agent > >> > fragment) using JSON. > >> > _______________________________________________ > >> > 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 > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > > _______________________________________________ > 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
