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" <jric...@mitre.org> 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 > >> 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
