Subject: [OAUTH-WG] temperature check: json input to token endpoint

From: Brian Eaton <[email-masked]>
Date: Sat, 10 Jul 2010 21:31:18 -0700

Hey folks -

Today, the token endpoint takes form-encoded inputs, and sends JSON
outputs.  This requires developers to use both form encoding and a
json parser.

Many services expose symmetric APIs for non-browser endpoints.  For
example, an API call normally takes JSON input and returns JSON
output.

What do people think about having the token endpoint accept and return JSON?

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 11 Jul 2010 07:21:07 +0200

that's a good idea from my point of view since it allows for more 
structured input.

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 12 Jul 2010 08:48:27 -0400

I'd like to keep form-encoded inputs. I think it makes sense to use a
well-established key-value mechanism, and the asymmetry at play here is
what the web is made of (post a form, get HTML/XML/JSON/whatever).

Along those lines, I'd actually like to relax the restriction of using
"POST" and allow for query arguments on the token endpoint as well. Long
ago it was argued that the POST requirement was to keep query parameters
from leaking into server logs. That's a fine implementation-specific
security optimization, but I don't think it belongs mandated in the
spec. As a practical matter, I know that for most of my implementations
(on small single servers), anyone who's got access to the web server
logs have access to the tokens in the database. 

Were there other reasons for mandating POST here that I'm forgetting?

 -- Justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 12 Jul 2010 06:56:29 -0700

Proxies and caches. 

EHL

---

From: Justin Richer <[email-masked]>
Date: Wed, 14 Jul 2010 11:38:27 -0400

Again, it's a good security optimization, and it makes sense for large
internet providers. But I don't think this argument holds for small
intranet providers, where there won't be proxies in the middle and many
of the clients will largely be non-browser-based and cacheless anyway.
At least, that's how it will be in most of my deployments. I think it
would be better to call out the cache/proxy/leakage issues directly,
recommend POST for most instances to address these concerns, but say
that a server MAY accept GET requests with query parameters on the token
endpoint. 

 -- Justin