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
