This is the same as having 2.1 compliance turned off by default. We already have a per-client setting to make PKCE mandatory.
If you can turn it off, what’s the point of making it a MUST in the spec? What does an optional MUST even mean for an AS to claim 2.1 compliance? > On 10 May 2020, at 21:19, Dick Hardt <dick.ha...@gmail.com> wrote: > > Is there a reason why a server can not support both OAuth 2.0 and OAuth 2.1? > The version supported could be dependent on the client id, ie older clients > could still be OAuth 2.0, and newer clients would be OAuth 2.1, and PKCE > would be enforced. > ᐧ > > On Sun, May 10, 2020 at 1:05 PM Neil Madden <neil.mad...@forgerock.com > <mailto:neil.mad...@forgerock.com>> wrote: > 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 <dick.ha...@gmail.com >> <mailto:dick.ha...@gmail.com>> 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 >> <Michael.Jones=40microsoft....@dmarc.ietf.org >> <mailto:40microsoft....@dmarc.ietf.org>> 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 <torsten=40lodderstedt....@dmarc.ietf.org >> <mailto:40lodderstedt....@dmarc.ietf.org>> >> Sent: Sunday, May 10, 2020 3:15 AM >> To: Mike Jones <michael.jo...@microsoft.com >> <mailto:michael.jo...@microsoft.com>> >> Cc: Daniel Fett <f...@danielfett.de <mailto:f...@danielfett.de>>; >> oauth@ietf.org <mailto:oauth@ietf.org> >> Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE? >> >> >> >> Hi Mike, >> >> >> >> Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org >> <mailto:40microsoft....@dmarc.ietf.org>> 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 <oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>> On >> Behalf Of Daniel Fett >> Sent: Thursday, May 7, 2020 11:50 PM >> To: oauth@ietf.org <mailto:oauth@ietf.org> >> 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 <dick.ha...@gmail.com >> <mailto: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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth>_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> ᐧ >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
