Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

[Torsten Lodderstedt <[e-mail]>]

Mike Jones <[e-mail]> schrieb am Sa. 9. Mai 2020 um
20:46:

> There’s a huge ecosystem of successful, secure OAuth 2.0 and OpenID
> Connect deployments that we have the responsibility to be stewards of.
> This working group should be proud of what it’s accomplished.  Part of good
> stewardship is not unnecessarily bifurcating the ecosystem into
> non-interoperable segments.  OAuth 2.1 should facilitate the already secure
> OAuth 2.0 deployments remaining part of the interoperable OAuth 2.1 set of
> deployments – not intentionally doing the opposite.
>
>
>
> If it ain’t broke, don’t fix it!
>
Did I got it right that nonce does not protect public clients from code
theft/replay? I would consider this a security issue.

>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki <[e-mail]>
> *Sent:* Friday, May 8, 2020 8:34 PM
> *To:* OAuth WG <[e-mail]>
> *Cc:* Dick Hardt <[e-mail]>; Torsten Lodderstedt <
> [e-mail]>; Mike Jones <[e-mail]>
> *Subject:* Re: OAuth 2.1 - require PKCE?
>
>
>
> Aaron, I believe you’re trying to optimize the wrong thing.  You’re
> concerned about “the amount of explanation this will take”.  That’s
> optimizing for spec simplicity – a goal that I do understand.  However, by
> writing these few sentences or paragraphs, we’ll make it clear to
> developers that hundreds or thousands of deployed OpenID Connect RPs won’t
> have to change their deployments.  That’s optimizing for interoperability
> and minimizing the burden on developers, which are far more important.
>
>
>
> I appreciate the concern about optimizing for spec simplicity. I also
> agree that spec simplicity should not necessarily be the driving goal.
>
>
>
> However, what you've described is the opposite of interoperability and
> minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without
> any exceptions, will optimize for interoperability between OAuth 2.1
> clients and servers. Without the requirement of PKCE, there will always be
> the question of "but does this OAuth 2.1 client work with this OAuth 2.1
> server or not?", which will only be able to be answered by investigating
> the docs to look for PKCE support, or by checking the AS metadata document
> if it publishes one (which it is not required to do).
>
>
>
> Optimizing for interoperability and minimizing the burden on developers is
> absolutely a good goal, and requiring PKCE is a great way to accomplish
> that. OAuth 2.0 and OpenID Connect implementations that don't support PKCE
> will continue to work as they currently do, they just won't be able to call
> themselves OAuth 2.1 compliant, just as is the case as if they don't follow
> the other recommendations that are in OAuth 2.1 and the Security BCP.
>
>
>
> Aaron
>
>
>
>
>
> On Thu, May 7, 2020 at 6:42 PM Mike Jones <[e-mail]>
> wrote:
>
> Aaron, I believe you’re trying to optimize the wrong thing.  You’re
> concerned about “the amount of explanation this will take”.  That’s
> optimizing for spec simplicity – a goal that I do understand.  However, by
> writing these few sentences or paragraphs, we’ll make it clear to
> developers that hundreds or thousands of deployed OpenID Connect RPs won’t
> have to change their deployments.  That’s optimizing for interoperability
> and minimizing the burden on developers, which are far more important.
>
>
>
> As Brian Campbell wrote, “They are not equivalent and have very different
> ramifications on interoperability”.
>
>
>
> Even if you’re optimizing for writing, taking a minimally invasive
> protocol change approach will optimize that, overall.  If we proceed as
> you’re suggesting, a huge amount of writing will occur on StackOverflow,
> Medium, SlashDot, blogs, and other developer forums, where confused
> developers will ask “Why do I have to change my deployed code?” with the
> answers being “Despite what the 2.1 spec says, there’s no need to change
> your deployed code.”
>
>
>
> I’d gladly write a few sentences in our new specs now to prevent ongoing
> confusion and interop problems that would otherwise result.  Let me know
> when you’re ready to incorporate them into the spec text.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki <[e-mail]>
> *Sent:* Thursday, May 7, 2020 4:39 PM
> *To:* Dick Hardt <[e-mail]>
> *Cc:* OAuth WG <[e-mail]>; Torsten Lodderstedt <
> [e-mail]>; Mike Jones <[e-mail]>
> *Subject:* Re: OAuth 2.1 - require PKCE?
>
>
>
> Backing up a step or two, there's another point here that I think has been
> missed in these discussions.
>
>
>
> PKCE solves two problems: stolen authorization codes for public clients,
> and authorization code injection for all clients. We've only been talking
> about authorization code injection on the list so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE as
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP for
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt <[e-mail]> wrote:
>
> 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
>
>
>
> ᐧ
>
>