I support keeping those two in a single document.
They actually belong to a same class of problem: the problem of accepting
an input from an untrusted / un-protected source, i.e., the authorization
response.
When this vulnerability is applied to the 'state', it opens up the chance
of authorization
I think Toresen states it well.
The reason we looked at 2 again is that #1 in some of the attacks was being
used to leak the code.
In some of those cases the attacker had the client credentials and could use
the directly to get access tokens.
In other cases the attacker doesn’t have the clien
Hi Hannes,
#2 is not directly described in the paper but was used to replay the
code/token the attacker obtained via #1. In my observation, the
discussion in Darmstadt has shown that OAuth (and its built-in
mitigations) so far focused on preventing code/token leakage but we lake
mitigation fo
Hi all,
when I posted the call for adoption of the 'OAuth 2.0 Mix-Up Mitigation'
solution I wasn't expecting such a
heavy debate on the list. While the call for adoption is still ongoing I
would like to share my view as someone who has to judge consensus in a
few days together with Derek.
Regard
