To be clear, you are +1 on using only JSON for server responses on the 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<mailto: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: * Canonicalization of parameters for signing, and * 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> [mailto: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<mailto: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<mailto:say...@gmail.com>> wrote: +1 On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <n...@daaku.org<mailto:n...@daaku.org>> wrote: > +1 > > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard > <lshep...@facebook.com<mailto: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> >> > [mailto: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<mailto: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<mailto:OAuth@ietf.org> >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org<mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
