> The _*safest*_ thing for a client is to accept both. I politely (and strongly) disagree with this statement. The safest thing for a client is to only accept POST or other verbs where any kind of sensitive data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, even over HTTPS.
Respectfully, Jim On 8/11/17 3:18 PM, John Bradley wrote: > OpenID Connect formally defined a POST response mode. > > http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html > > The OAuth 2 spec docent preclude it. > > The safest thing for a client is to accept both. > The main advantages of POST is that it docent leak in the referrer, > and can handle larger responses without the browser choking in some cases. > > Size is more of an issue in Connect where a id_token may be returned > in the front channel and POST allows for the larger response without > the client needing to have JS extract the fragment. > > That is why Connect defined it and OAuth largely assumes that for code > get is OK. > For security GET responses should add headers to prevent referrer from > leaking the code. > > We are adding advice on that to the Security document that is being > updated now. > > John B. > > >> On Aug 11, 2017, at 4:08 PM, Josh Mandel <jman...@gmail.com >> <mailto:jman...@gmail.com>> 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 <jman...@gmail.com >> <mailto:jman...@gmail.com>> 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 >> <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 >> <https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63%29>) >> 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 >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Jim Manico Manicode Security https://www.manicode.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
