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

> Rejecting a GET with code in the URL means that the code is never "used" at the AS, so can still be exchanged for an access token; and rejecting the request does not mean it won't leak That's a good point Thomas. I still think secure OAuth workflows should totally avoid putting any kind of sensi

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

Rejecting a GET with code in the URL means that the code is never "used" at the AS, so can still be exchanged for an access token; and rejecting the request does not mean it won't leak. So reject if you like from the user's point of view, but "consume" the code anyway (and then immediately revoke t

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

> Get is mostly OK with the correct headers to stop referrer leakage. Those work in new-ish browsers only. Referrer is only one GET leakage vector. > Fragment should only be used with real JS clients in the browser and not > with servers. Fragment behavior is very different in modern browser

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

>From a interoperability perspective accepting both is best. Get is mostly OK with the correct headers to stop referer leakage. Fragment should only be used with real JS clients in the browser and not with servers. That is the general direction of the new security advice. People wanting to use P

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

> 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.

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

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

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