> On 11 May 2020, at 08:05, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > > > >>> On 11. May 2020, at 08:47, Neil Madden <neil.mad...@forgerock.com> wrote: >>> >>> >>> >>>> On 11 May 2020, at 07:41, Torsten Lodderstedt <tors...@lodderstedt.net> >>>> wrote: >>> >>>> On 11. May 2020, at 07:38, Neil Madden <neil.mad...@forgerock.com> wrote: >>>> >>>> There is no attack that this prevents so your claim of improving security >>>> is unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default >>>> AS while this requirement remains so I don’t support it. >>> >>> Are you saying PKCE does not prevent any attack? >> >> No, but servers and clients are already free to support PKCE. I’m saying >> that rejecting requests from non-PKCE clients doesn’t prevent any attack. It >> just denies service to legitimate clients. > > There are two aspects to this topic: > > 1) Do all ASs support PKCE? Requiring PKCE support fosters interoperability > and security. Security since the client can be sure the AS supports PKCE. > Today, if the AS does not support PKCE, the client will never learn since a > compliant AS will just ignore additional request parameters.
But just saying that a 2.1 AS MUST support PKCE is enough for this. Rejecting requests just to support feature discovery is a sledgehammer to crack a nut. > > 2) Do ASs enforce PKCE? This fosters security since it forces clients to > implement a means against code replay and CSRF. > Again, just saying that 2.1 clients MUST support PKCE achieves this aim. Rejecting non-PKCE requests doesn’t add anything to security. And as has been pointed out elsewhere in this thread there are clients that don’t benefit from PKCE such as confidential OIDC clients. Indeed for most confidential clients the gains of PKCE are relatively minor - code injection attacks are already pretty hard to pull off in practice against such clients. Neil _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
