+1 Phil
> On May 7, 2020, at 11:50 PM, Daniel Fett <f...@danielfett.de> wrote: > > > +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> 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
