FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is OAuth 2.0 with best practices.
On Thu, May 7, 2020 at 10:36 PM Philippe De Ryck < [email protected]> wrote: > From working with a lot of developers on understanding OAuth 2.0 and OIDC, > I definitely vote for simplicity. Understanding the subtle nuances of when > a nonce is fine and when PKCE should be used is impossible without in-depth > knowledge of the flows and their properties. Misunderstandings will cause > security vulnerabilities, which can easily be avoided. > > Since OAuth 2.1 is a separate spec, I don’t really see a problem with > existing code not being compliant. They support OAuth 2.0, and if they want > to be OAuth 2.1 compliant, they add PKCE. If I’m not mistaken, other > requirements of OAuth 2.1 would also clash with existing deployments (e.g.., > using non-exact redirect URIs). > > I believe that optimizing for making OAuth 2.1 easier to understand will > yield the highest return. > > Philippe > > > On 8 May 2020, at 03:42, Mike Jones < > [email protected]> 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 <[email protected]> > *Sent:* Thursday, May 7, 2020 4:39 PM > *To:* Dick Hardt <[email protected]> > *Cc:* OAuth WG <[email protected]>; Torsten Lodderstedt < > [email protected]>; Mike Jones <[email protected]> > *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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
