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.

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 <jmandel@gmail.com
>> <mailto:jmandel@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 <jmandel@gmail.com
>> <mailto:jmandel@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