But if an AS upgrades to OAuth 2.1 then it MUST reject authorization requests that don’t include a code_challenge (section 4.1.2.1), so this will only be possible when all clients support PKCE.
This makes it impossible for a 2.1-compliant AS to also support non-PKCE 2.0 clients (i.e., the vast majority of them). I think we can have a 2.1 spec that says clients and servers MUST support PKCE without this hard-fail clause. Otherwise I can’t see how we’d ever ship with 2.1-compliance enabled out-of-the-box. — Neil > On 10 May 2020, at 20:38, Dick Hardt <[email protected]> wrote: > > Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as the > other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth 2.0 was > voluntary. > > Would you clarify why you think upgrading to OAuth 2.1 would be mandatory? > > > On Sun, May 10, 2020 at 12:02 PM Mike Jones > <[email protected] > <mailto:[email protected]>> wrote: > I agree with actively maintaining and improving the OAuth 2.0 specs by adding > enhancements that are voluntary to use. I’ve worked on many such > improvements, including Dynamic Client Registration, Authorization Metadata, > the Device Flow, Token Exchange, DPoP, and support PAR and RAR, etc. The > issue that’s the subject is the current discussion is whether to make use of > another enhancement, PKCE, mandatory in cases where it’s actually not needed, > rather than making its use voluntary like the other enhancements, which I > certainly support. > > > > -- Mike > > > > From: Torsten Lodderstedt <[email protected] > <mailto:[email protected]>> > Sent: Sunday, May 10, 2020 3:15 AM > To: Mike Jones <[email protected] > <mailto:[email protected]>> > Cc: Daniel Fett <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > > > Hi Mike, > > > > Mike Jones <[email protected] > <mailto:[email protected]>> schrieb am Fr. 8. Mai 2020 um 18:55: > > OAuth 2.1 was supposed to not introduce breaking changes. > > I cannot remember the WG met that decision. Can you please refer to the > respective thread? > > > > Requiring exact redirect URI matching is already a breaking change. Do you > oppose against this as well? > > > > > > If you want to do that, please do it in TxAuth instead. > > > > Interesting statement. Does it mean you want to conserve OAuth 2.0 and force > any enhancements/improvements to go into TXAuth? This would cause huge > migration efforts for existing deployments wanting to benefit from those > enhancements. > > > > I think existing deployments are better served by actively maintaining and > evolving the 2.x line. For example, PAR and RAR are attempts to improve OAuth > 2.x and make it usable for new use cases. That’s better protection of > existing investments than sending them of to TXAuth. > > Kind regards, > > Torsten. > > > > > > -- Mike > > > > From: OAuth <[email protected] <mailto:[email protected]>> On > Behalf Of Daniel Fett > Sent: Thursday, May 7, 2020 11:50 PM > To: [email protected] <mailto:[email protected]> > Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > > > +1 to all what Aaron said. Thanks for pointing this out! > > > > We need to address this in the security BCP and this will be a normative > change that affects OpenID Connect Core (just as our current recommendation > on the usage of nonce). > > > > We would then have: > > > > - use PKCE, except if you use OIDC with a nonce, then you don't need PKCE, > except if you are a public client, then you still need PKCE. > > - use state, except if you use PKCE, then you don't need state. > > > > I think there are very good reasons to simplify this down to > > > > - use PKCE > > - you may or may not use state > > > > First and foremost, not many people will understand why there are cases when > the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, > understanding why you have to do something is key to compliance. The short > version "PKCE protects the code; there is a specific case where it is not > needed, but its better to use it all the time" is easy to understand. We will > not see many implementations following the long version above correctly. > > > > Second, we dramatically reduce technical complexity by reducing cases that > need to be handled. We reduce correctness and compliance testing complexity > in the same way. We reduce the cost of security analysis, which scales really > badly to more cases. > > > > And finally, using nonce to protect against code injection is less robust > than PKCE. AS have a better track record than clients when it comes to > correctly implementing security mechanisms. > > > > Yes, this will make a number of implementations non-spec-compliant, but I do > not think that this is a huge problem. Software needs to adapt all the time > and a software that has not been changed in a while is probably not one you > would want to use anyway. We are setting a new goal for implementations to > meet and eventually, maintained implementations will get there. > > > > -Daniel > > > > > > Am 08.05.20 um 01:38 schrieb Aaron Parecki: > > 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] > <mailto:[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>_______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > ᐧ > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
