On Sat, 30 May 2020 at 17:59, Daniel Fett <f...@danielfett.de> wrote:
> Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE
> [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the
> conclusion that we have two options:
>
[..snip..]
> *2. "Dynamic" Solution*
>
> Each AS that supports PKCE MUST check whether a code challenge is
> contained in the authorization request. This information MUST be bound to
> the code that is issued.
>
> When a code arrives at the token endpoint, the AS MUST do the following
> check:
>
> 1. If there was a code_challenge in the authorization request for
> which this code was issued, there must be a code_verifier in the token
> request and it must be verified according to RFC7636. (This is no change
> from the current behavior in RFC7636.)
> 2. If there was no code_challenge in the authorization request, any
> request to the token endpoint containing a code_verifier MUST be rejected.
>
> Properties:
>
> - No change in behavior needed for properly implemented clients.
> Backwards compatible for all existing deployments.
> - Implementation is mainly some logic for the authorization endpoint,
> token endpoint, and a new data field in the authorization session
> maintained by the AS.
> - Slightly more complex to implement for the AS, maybe.
>
> We would like to hear the feedback from the working group on these two
> solutions before proceeding to propose wording for the affected documents.
>
When we added PKCE support in Firefox Accounts, we implemented the
suggested check (2) above purely as a defensive-coding measure, expecting
that it might help us catch buggy clients. I think it makes sense to add as
a required behaviour since it seems like a pretty clear signal of
mismatched expectations between client and server.
Cheers,
Ryan
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
