Yes, the BCP says *clients* may use either PKCE or nonce to prevent authorization code injection. Shortly after that quoted segment is the below:
> Authorization servers MUST support PKCE [RFC7636]. On Wed, May 6, 2020 at 12:22 PM Mike Jones <michael.jo...@microsoft.com> wrote: > Aaron, the section you cited at > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2..1.1 > makes it clear that clients can support EITHER PKCE or the OpenID Connect > nonce. The text is: > > > > Clients MUST prevent injection (replay) of authorization codes into > > the authorization response by attackers. The use of PKCE [RFC7636 > <https://tools.ietf.org/html/rfc7636>] > > is RECOMMENDED to this end. The OpenID Connect "nonce" parameter and > > ID Token Claim [OpenID > <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#ref-OpenID>] > MAY be used as well. The PKCE challenge or > > OpenID Connect "nonce" MUST be transaction-specific and securely > > bound to the client and the user agent in which the transaction was > > started. > > > > We should not attempt to change that in OAuth 2.1, as doing so would > needlessly break already working and secure clients. > > > > -- Mike > > > > *From:* Aaron Parecki <aa...@parecki.com> > *Sent:* Wednesday, May 6, 2020 11:56 AM > *To:* Mike Jones <michael.jo...@microsoft.com> > *Cc:* Dick Hardt <dick.ha...@gmail.com>; oauth@ietf.org > *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > > > > In particular, authorization servers shouldn’t be required to support > PKCE when they already support the OpenID Connect nonce. > > > > The Security BCP already requires that ASs support PKCE: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2..1.1 > Are > you suggesting that the Security BCP change that requirement as well? If > so, that's a discussion that needs to be had ASAP. If not, then that's an > implicit statement that it's okay for OpenID Connect implementations to not > be best-practice OAuth implementations. And if that's the case, then I also > think it's acceptable that they are not complete OAuth 2.1 implementations > either. > > > > > > > > > > > > > > On Wed, May 6, 2020 at 11:21 AM Mike Jones <Michael.Jones= > 40microsoft....@dmarc.ietf.org> wrote: > > The disadvantage of requiring PKCE for OpenID Connect implementations is > that you’re trying to add a normative requirement that’s not required of > OpenID Connect deployments today, which would bifurcate the ecosystem. > There are hundreds of implementations (including the 141 certified ones at > https://openid.net/certification/), none of which have ever been required > to support PKCE. Therefore, most don’t. > > > > Per feedback already provided, I believe that OAuth 2.1 should align with > the guidance already in the draft Security BCP, requiring EITHER the use of > PKCE or the OpenID Connect nonce. Trying to retroactively impose > unnecessary requirements on existing deployments is unlikely to succeed and > will significantly reduce the relevance of the OAuth 2.1 effort. > > > > In particular, authorization servers shouldn’t be required to support PKCE > when they already support the OpenID Connect nonce. And clients shouldn’t > reject responses from servers that don’t support PKCE when they do contain > the OpenID Connect nonce. Doing so would unnecessarily break things and > create confusion in the marketplace. > > > > -- Mike > > > > *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of *Dick Hardt > *Sent:* Wednesday, May 6, 2020 10:48 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE? > > > > Hello! > > > > We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best > practice for OAuth 2.0. It is not common in OpenID Connect servers as the > nonce solves some of the issues that PKCE protects against. We think that > most OpenID Connect implementations also support OAuth 2.0, and hence have > support for PKCE if following best practices. > > > > The advantages or requiring PKCE are: > > > > - a simpler programming model across all OAuth applications and profiles > as they all use PKCE > > > > - reduced attack surface when using S256 as a fingerprint of the verifier > is sent through the browser instead of the clear text value > > > > - enforcement by AS not client - makes it easier to handle for client > developers and AS can ensure the check is conducted > > > > What are disadvantages besides the potential impact to OpenID Connect > deployments? How significant is that impact? > > > > Dick, Aaron, and Torsten > > > > ᐧ > > _______________________________________________ > 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
