> 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
