> On 10. May 2020, at 21:02, Mike Jones <michael.jo...@microsoft.com> wrote: > > > Did I got it right that nonce does not protect public clients from code > > theft/replay? > > I believe that the OpenID Connect Code Hash (“c_hash”) claim protects against > this.
c_hash is designed to prevent injection at a legit client and must be enforced by the client - just like nonce. That might work with a confidential client, but in case of a public client, the attacker does not need to inject the code in order to redeem it. The attacker can just directly redeem the code for an access token without checking c_hash or nonce. > I’d be interested in hearing John Bradley’s take on this. > > -- Mike > > From: Torsten Lodderstedt <tors...@lodderstedt.net> > Sent: Sunday, May 10, 2020 3:17 AM > To: Mike Jones <michael.jo...@microsoft.com> > Cc: Aaron Parecki <aa...@parecki.com>; Dick Hardt <dick.ha...@gmail.com>; > OAuth WG <oauth@ietf.org> > Subject: Re: OAuth 2.1 - require PKCE? > > Mike Jones <michael.jo...@microsoft.com> 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 <aa...@parecki.com> > Sent: Friday, May 8, 2020 8:34 PM > To: OAuth WG <oauth@ietf.org> > Cc: Dick Hardt <dick.ha...@gmail.com>; Torsten Lodderstedt > <tors...@lodderstedt.net>; Mike Jones <michael.jo...@microsoft.com> > 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 <michael.jo...@microsoft.com> 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 <aa...@parecki.com> > Sent: Thursday, May 7, 2020 4:39 PM > To: Dick Hardt <dick.ha...@gmail.com> > Cc: OAuth WG <oauth@ietf.org>; Torsten Lodderstedt <tors...@lodderstedt.net>; > Mike Jones <michael.jo...@microsoft.com> > 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 <dick.ha...@gmail.com> 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 > > ᐧ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
