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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
