I need to think about it a bit, however off the top of my head based on the
attack described the code flow should still be safe if the code is truly single
use. (Some implementations fudge that)
If the attacker can stop the browser from delivering the code to the client
then the client would be susceptible to the cut and paste attack for injecting
the code back into the client.
The OpenID Connect “code id_token” flow is not vulnerable to this if the client
is properly validating the id_token.
I suspect that this would work against the implicit flow if the JS is sending
the code back to its web server via a GET.
That I think we recommend against doing, or should.
The Token binding proposals would stop a leaked code from being used, but not
from being stolen in this attack.
The attack against a confidential client would be the cut and paste one that we
have identified. Currently the only mitigation we have is “code id_token” so
the blog post at.
http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/
I the most relevant current advice.
The thing to add is that the code leaked in this way should not be repayable at
the client
I don’t think that native apps are vulnerable to this if they are using custom
scheme redirects.
I don’t know what the risk is if they are using loopback or claimed URI. It
may be that a browser might leak them in the same way.
That would need to be tested.
John B.
Sent from Mail for Windows 10
From: Dick Hardt
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
