I would take it a step further. GET's leak parameters even over HTTPS. I advise all GET based OAuth communication to be switched to POST, a much more security centric verb.
Aloha, -- Jim Manico > On Aug 11, 2017, at 3:08 PM, Josh Mandel <[email protected]> wrote: > > Fixing my "with this technique" url: it should have been > https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 . > >> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <[email protected]> wrote: >> Hi All, >> >> I've just encountered a server that performs a redirect (back to the >> client's redirect_uri) via POST instead of GET. This was surprising behavior >> to me and broke my client implementation — but citing chapter and verse, the >> server developer pointed out that >> https://tools.ietf.org/html/rfc6749#section-1.7 says >> >>> While the examples in this specification show the use of the HTTP 302 >>> status code, any other method available via the user-agent to accomplish >>> this redirection is allowed and is considered to be an implementation >>> detail. >> >> Is triggering a POST-based redirect (e.g. with this technique) to the >> redirect_url (including url query parameters for state and code) indeed >> considered a "method available via the user-agent to accomplish this >> redirection"? In other words, should a well-behaved OAuth client be prepared >> to receive GETs as well as POSTs to its redirect_uri? If so, what would be >> the considerations for a server choosing between GET and POST? >> >> Best, >> >> Josh > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
