We (ForgeRock) already support solution 1 as a configuration option, but I prefer solution 2 and have raised a ticket for us to implement it. For us at least it’s a trivial fix and seems more robust against configuration errors.
— Neil > On 30 May 2020, at 08:58, Daniel Fett <f...@danielfett.de> wrote: > > Hi all, > > 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: > > 1. "Static" Solution > > For every client_id that is registered with an AS, the AS MUST either always > enforce the use of PKCE or always enforce the use of nonce. Whether PKCE or > nonce is enforced can be part of the client registration or configured in > other ways. > > In other words: A single client is not allowed to switch between using PKCE > and using nonce. > > Note that the client is allowed to use the respective other mechanism on top > of the enforced one. > > Properties: > Easy to understand mitigation. > Implementation is mainly a new data field and a check in the authorization > request. > Not compatible to deployments where clients sometimes use nonce and sometimes > use PKCE with the same client_id. > 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: > > 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.) > 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. > > [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ > <https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/> > > -Daniel > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
