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
