OpenID Connect formally defined a POST response mode. http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html <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> wrote: > > Fixing my "with this technique" url: it should have been > https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 > <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)>) 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 > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
