Subject: [OAUTH-WG] Proposal for single JSON response format

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 10 Jun 2010 13:29:06 -0700

After taking a break from our previous debate(s) on the issue of which response format to support, I would like to suggest the following:

- Support a single response format (including in the user-agent fragment) using JSON.

My reason for this is very simple, while right now we have a very limited need (key/value pairs), we already have a few proposals which require a richer syntax. As OAuth matures, I expect more and more extensions to make use of the server response to include additional parameters (flat or structured). By using JSON, we can very easily support "namespaces" (i.e. { "access_token":"xyz","ext":{...} }), multiple token in a single response, etc.

I appreciate the simplicity in using form-encoded (both code and library dependency wise), but long term, it will create a real limitation and will require extensions to also specify a different response format.

Those worried about the need to include a JSON library in cases where it will be hard to do (embedded devices, etc.), can always extend the protocol to provide a way to receive key/value form-encoded pairs. However, they will need to figure out how to accommodate structured responses if they wish support it. I am certain that the vast majority of implementations will have no problem including a JSON library.

Please respond only with yes or no (+/- 1). If you have a different proposal, please post it in a new thread. If you are going to vote against this, please indicate if your objection is blocking (i.e. you are opposed to it and will block a consensus call with this approach).

EHL

---

From: Justin Hart <[email-masked]>
Date: Thu, 10 Jun 2010 13:32:15 -0700

+1 for MUST JSON response, MAY form-encoded (and xml, etc etc) response via extension (response_format parameter?)
----
-- Justin Hart
-- [email-masked]

On Jun 10, 2010, at 2:29 PM, Eran Hammer-Lahav wrote:

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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 10 Jun 2010 13:34:36 -0700

+1

---

From: Michael D Adams <[email-masked]>
Date: Thu, 10 Jun 2010 13:36:38 -0700

+1

---

From: David Recordon <[email-masked]>
Date: Thu, 10 Jun 2010 13:48:26 -0700

+1

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 Jun 2010 16:51:47 -0400

+1

Propose we have other encodings as extensions, then.

 -- justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 10 Jun 2010 23:19:13 +0200

+1

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 10 Jun 2010 15:11:11 -0700

+1 with optional extension for XML encoded

-cmort

On 6/10/10 1:29 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

---

From: Brian Eaton <[email-masked]>
Date: Thu, 10 Jun 2010 15:18:56 -0700

+1.

---

From: Nat <[email-masked]>
Date: Fri, 11 Jun 2010 07:21:01 +0900

+1

=nat @ Tokyo via iPhone

On 2010/06/11, at 7:18, Brian Eaton <[email-masked]> wrote:

> +1.
>
> On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav <[email-masked] 
> > wrote:
>> After taking a break from our previous debate(s) on the issue of  
>> which response format to support, I would like to suggest the  
>> following:
>>
>> My reason for this is very simple, while right now we have a very  
>> limited need (key/value pairs), we already have a few proposals  
>> which require a richer syntax. As OAuth matures, I expect more and  
>> more extensions to make use of the server response to include  
>> additional parameters (flat or structured). By using JSON, we can  
>> very easily support "namespaces" (i.e. { "access_token":"xyz","ext": 
>> {...} }), multiple token in a single response, etc.
>>
>> I appreciate the simplicity in using form-encoded (both code and  
>> library dependency wise), but long term, it will create a real  
>> limitation and will require extensions to also specify a different  
>> response format.
>>
>> Those worried about the need to include a JSON library in cases  
>> where it will be hard to do (embedded devices, etc.), can always  
>> extend the protocol to provide a way to receive key/value form- 
>> encoded pairs. However, they will need to figure out how to  
>> accommodate structured responses if they wish support it. I am  
>> certain that the vast majority of implementations will have no  
>> problem including a JSON library.
>>
>> Please respond only with yes or no (+/- 1). If you have a different  
>> proposal, please post it in a new thread. If you are going to vote  
>> against this, please indicate if your objection is blocking (i.e.  
>> you are opposed to it and will block a consensus call with this  
>> approach).
>>
>> EHL

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 11 Jun 2010 10:46:20 +1000

+1

--
James Manger

----------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, 11 June 2010 6:29 AM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] Proposal for single JSON response format

---

From: Luke Shepard <[email-masked]>
Date: Thu, 10 Jun 2010 17:50:35 -0700

+1

---

From: Naitik Shah <[email-masked]>
Date: Thu, 10 Jun 2010 22:17:30 -0700

+1

---

From: Robert Sayre <[email-masked]>
Date: Fri, 11 Jun 2010 16:51:46 -0400

+1

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Evan Gilbert <[email-masked]>
Date: Sun, 13 Jun 2010 02:46:42 -0700

-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 <[email-masked]> wrote:

> >> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> > Of Eran Hammer-Lahav

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 13 Jun 2010 08:18:12 -0700

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?

If all server responses are JSON, why does the client have to do form-decoding?

What simple model? Format isn't a model.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Evan Gilbert
Sent: Sunday, June 13, 2010 2:47 AM
To: Robert Sayre
Cc: OAuth WG ([email-masked])
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 <[email-masked]<mailto:[email-masked]>> wrote:
+1

On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <[email-masked]<mailto:[email-masked]>> wrote:
> +1
>
> On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> +1
>>
>> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>> > Of Eran Hammer-Lahav
>> > To: OAuth WG ([email-masked]<mailto:[email-masked]>)
>> > [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Evan Gilbert <[email-masked]>
Date: Sun, 13 Jun 2010 11:20:17 -0700

On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav <[email-masked]>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.
>
>
>

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

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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Evan Gilbert
> *Sent:* Sunday, June 13, 2010 2:47 AM
> *To:* Robert Sayre
> *Cc:* OAuth WG ([email-masked])
> *Subject:* Re: [OAUTH-WG] Proposal for single JSON response format
>
>
>
> -1
>
>
>
> 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
> 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:
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 13 Jun 2010 17:23:48 -0700

On 2010-06-13, at 11:20 AM, Evan Gilbert wrote:

> 
> 
> On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> 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 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 a response from the AS is untrusted, there are much bigger issues at stake. ... or am I missing an obvious attack where random JSON would get sent to the Client?

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 13 Jun 2010 17:55:39 -0700

To be clear, you are +1 on using only JSON for server responses on the token endpoint?

EHL

From: Evan Gilbert [mailto:[email-masked]]
Sent: Sunday, June 13, 2010 11:20 AM
To: Eran Hammer-Lahav
Cc: Robert Sayre; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Proposal for single JSON response format

On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> 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.

Naive processor calls:

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.

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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Evan Gilbert
Sent: Sunday, June 13, 2010 2:47 AM
To: Robert Sayre
Cc: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Proposal for single JSON response format

-1

Evan

--

Robert Sayre

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 14 Jun 2010 09:39:53 -0700

+1 on JSON in response bodies
-1 on JSON in URL query parameters or fragments.

Dirk.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 10:00:46 -0700

So far we have 16 people supporting using JSON as the only response format for the token endpoint with no objections. Draft -07 reflects this change. I am considering this matter closed, but if someone has a late objection, feel free to raise it.

As for using JSON in the fragment or query of the end-user authorization endpoint response, two people voiced specific objections to that. For now, -07 contains an editorial note about that option (using JSON). I think it is worth further (separate) discussion.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Mon, 14 Jun 2010 10:15:33 -0700

On Mon, Jun 14, 2010 at 10:00 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> So far we have 16 people supporting using JSON as the only response format
> for the token endpoint with no objections. Draft -07 reflects this change. I am
> considering this matter closed, but if someone has a late objection, feel free to raise it.
>
> As for using JSON in the fragment or query of the end-user authorization
> endpoint response, two people voiced specific objections to that. For now,
> -07 contains an editorial note about that option (using JSON). I think it is
> worth further (separate) discussion.

Sounds good to me.

(I completely missed that the proposal was to use JSON in redirect
URLs.  Evan, thanks for catching that, and Eran, thanks for flagging
it as something that requires more discussion.)

Cheers,
Brian

---

From: Dick Hardt <[email-masked]>
Date: Mon, 14 Jun 2010 14:12:04 -0700

+1 (JSON in direct response, separate discussion on redirect response)

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 14 Jun 2010 21:35:18 -0700

> To be clear, you are +1 on using only JSON for server responses on the
Yes, +1 on JSON responses for token endpoint.

>
>
> EHL
>
>
>
> *From:* Evan Gilbert [mailto:[email-masked]]
> *Sent:* Sunday, June 13, 2010 11:20 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Robert Sayre; OAuth WG ([email-masked])
>
> 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

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 14 Jun 2010 21:41:05 -0700

>
>
> If a response from the AS is untrusted, there are much bigger issues at
> stake. ... or am I missing an obvious attack where random JSON would get
> sent to the Client?
>

For the web server flow, you know the AS server you called and can
reasonably trust the data.

For the user agent flow, attackers can create a URL with data and send it to
you. This is OK (kind of) if the data is limited to an access token - this
would allow an attacker to grant you access to their protected resources,
which only has problems if you accidentally send protected data in an update
to that account. But if you have other parameters that need to be vouched
for by the AS, then it is insecure.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 14 Jun 2010 22:59:08 -0700

On 2010-06-14, at 9:41 PM, Evan Gilbert wrote:

> For the web server flow, you know the AS server you called and can reasonably trust the data.
> 
> For the user agent flow, attackers can create a URL with data and send it to you. This is OK (kind of) if the data is limited to an access token - this would allow an attacker to grant you access to their protected resources, which only has problems if you accidentally send protected data in an update to that account. But if you have other parameters that need to be vouched for by the AS, then it is insecure.

Understood. I have concerns about JSON in the user agent flow. My original JSON proposal was using JSON in the response for direct calls only.

-- Dick