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 protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
