Hi Joseph,
Among these 39 slides, to which attack(s) are you referring ?
I wrote:"It is quite hard to understand under which /context(s) /and
conditions OAuth 2.0 could be safely used".
For each counter-measure, it would be useful to explain under which
context(s) or under which assumptions
it should be used.
Denis
Hi Denis,
On 22 May 2018, at 14:05, Denis <denis.i...@free.fr
<mailto:denis.i...@free.fr>> wrote:
In particular, the text states:
"Clients shall use PKCE [RFC7636] in order to (with the help
of the authorization server) detect and prevent attempts
to inject (replay) authorization codes into the authorization
response".
This is incorrect, since RFC7636 should be used when the
authorization code is returned from the authorization endpoint
within a communication path that is _not protected_ by Transport
Layer Security (TLS).
That is not really the full story as we've seen attacks where URLs
that you would expect to be protected by TLS are vulnerable; one
example is:
https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf
IMHO it would be sane to use PKCE anywhere where a code is returned in
the URL and there isn't another proof of possession / token binding
mechanism in play.
Joseph
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
