[OAUTH-WG] Redirection in authorization code flow: GET vs POST

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/rfc67

Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

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 wrote: > Hi All, > > I've just encountered a server that performs a redirect (back to the > client's redirect_uri) via POST ins

Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

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 wrote: > > Fixing my "with this technique" url: it shoul

Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

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 advantag