[OAUTH-WG] authorization code injection - draft-ietf-oauth-security-topics-13

[Aaron Parecki <[e-mail]>]

I read through the authorization code injection section
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.5
but didn't see a mention of this explicitly...

The guidance in 3.1.1 recommends using PKCE for confidential clients.
Section 3.1 says that  clients may use PKCE instead of "state" for
CSRF protection, in which case "'state' may be used again for its
original purpose".

My worry is that without using a unique state value per request, it
becomes less obvious that clients need to maintain state to avoid
being tricked into exchanging an attacker's authorization code.

If the client is using PKCE, then this isn't an issue of exchanging a
different valid authorization code. However it's an issue that the
client may leave itself open to attackers tricking it into exchanging
garbage authorization codes at the AS, possibly triggering rate limits
or security flags at the AS.

There is a partial sentence that hits on the point in 3.1, "clients
MUST only process redirect responses ... from the same user agent this
authorization request initiated with". My worry is that this isn't
enough guidance anymore if people are using non-random state values.
If clients are required to use a random state value, then they are
forced into a situation where they need to maintain state between
requests, which then prevents this problem.

Any thoughts on this? I am not sure exactly what the resolution should
be. I suppose either still requiring a random value in the "state"
parameter, or adding some guidance on how to link a redirect response
with an authorization request.

----
Aaron Parecki
aaronparecki.com