Subject: Re: [OAUTH-WG] POST-only on token endpoint? [was: temperature check: json input to token endpoint]

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 2 Sep 2010 10:23:13 -0700

Didn't see consensus on making any of these changes. Dropping from my queue.

EHL

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 8:38 AM
To: Eran Hammer-Lahav
Cc: Brian Eaton; [email-masked]
Subject: Re: [OAUTH-WG] POST-only on token endpoint? [was: temperature check: json input to token endpoint]

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

On Mon, 2010-07-12 at 09:56 -0400, Eran Hammer-Lahav wrote:
> Proxies and caches. 
> 
> EHL
> 
> 
> 
> On Jul 12, 2010, at 8:48, "Justin Richer" <[email-masked]> wrote:
> 
> > 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
> > 
> > On Sun, 2010-07-11 at 00:31 -0400, Brian Eaton wrote:
> >> 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
> >> _______________________________________________
> >> OAuth mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/oauth
> > 
> > 
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth