(It's a bit of a tangent, but having the PKCE for confidential clients severely cuts down on extra complexity for client platforms/development teams when an AS choses to allow it for some clients and not for others. Consistency here is a good thing, since it's fairly easy to implement the roundtrip through libraries.)
Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Oct 13, 2021 at 8:15 PM Jeff Craig <jeffcraig= 40google....@dmarc.ietf.org> wrote: > OAuth 2.1 makes PKCE a requirement. > > I'm of two minds about PKCE for Confidential Clients, but it isn't a > substantially more complex flow even if Confidential Clients benefit far > less from PKCE than Public Clients, and I see the benefit to always doing > it. > > I am inclined to agree that with PKCE, replay attacks are substantially > less of a risk, but I need to think more about this (and I missed today's > meeting, so I should look over the notes before commenting too deeply). > > On Wed, Oct 13, 2021 at 1:03 PM Warren Parad <wparad= > 40rhosys...@dmarc.ietf.org> wrote: > >> Thanks Aaron, that's a great point. In light of that, I would ask about >> the recommendation for non-SPA. I was under the impression that non-SPA's >> don't require the use of PKCE, which would make them vulnerable to replay >> attacks. Or am I missing something? >> >> Warren Parad >> >> Founder, CTO >> Secure your user data with IAM authorization as a service. Implement >> Authress <https://authress.io/>. >> >> >> On Wed, Oct 13, 2021 at 7:59 PM Neil Madden <neil.mad...@forgerock.com> >> wrote: >> >>> I wasn’t on the call either, so maybe I’m missing something. If you’re >>> using PKCE with the “plain” challenge type then both the auth code and the >>> verifier are exposed in redirect URI parameters in the user-agent aren’t >>> they? That seems a bit risky to drop the one-time use requirement. >>> >>> I can’t see anything in the minutes of the meeting describing the >>> difficulty of implementing the one-time use req. I seem to see >>> announcements for new globally-consistent high-scale cloud database >>> services every day - is this really that hard to implement? >>> >>> — Neil >>> >>> On 13 Oct 2021, at 18:41, Aaron Parecki <aa...@parecki.com> wrote: >>> >>> >>> Warren, I didn't see you on the interim call, so you might be missing >>> some context. >>> >>> The issue that was discussed is that using PKCE already provides all the >>> security benefit that is gained by enforcing single-use authorization >>> codes. Therefore, requiring that they are single-use isn't necessary as it >>> doesn't provide any additional benefit. >>> >>> If anyone can think of a possible attack by allowing authorization codes >>> to be reused *even with a valid PKCE code verifier* then that would warrant >>> keeping this requirement. >>> >>> --- >>> Aaron Parecki >>> >>> >>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad <wparad= >>> 40rhosys...@dmarc.ietf.org> wrote: >>> >>>> Isn't it better for it to be worded as we want it to be, with the >>>> implication being that of course it might be difficult to do that, but that >>>> AS devs will think long and hard about sometimes not denying the request? >>>> Even with MUST, some AS will still allow reuse of auth codes. Isn't that >>>> better than flat out saying: *sure, there's a valid reason* >>>> >>>> In other words, how do we think about RFCs? Do they exist to be >>>> followed to the letter or not at all? Or do they exist to stipulate this is >>>> the way, but acknowledge that not everyone will build a solution that holds >>>> them as law. >>>> >>>> Let's look at *SHOULD* >>>> >>>>> This word, or the adjective "RECOMMENDED", mean that there may exist >>>>> valid reasons in particular circumstances to ignore a particular item, but >>>>> the full implications must be understood and carefully weighed before >>>>> choosing a different course. >>>> >>>> >>>> I think *recommended* here is not sufficient nor are there valid >>>> reasons. "It's too hard" isn't really a valid reason. Isn't it better in >>>> this case for an AS to not be compliant with the RFC, than it is to relax >>>> this to SHOULD and have lots of AS thinking reusing auth codes is a viable >>>> solution, "because they are a special snowflake where SHOULD should apply". >>>> >>>> Are we setting the standard or instead attempting to sustain a number >>>> of "AS that are in compliance with the RFC"? >>>> >>>> >>>> Warren Parad >>>> >>>> Founder, CTO >>>> Secure your user data with IAM authorization as a service. Implement >>>> Authress <https://authress.io/>. >>>> >>>> >>>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones <Michael.Jones= >>>> 40microsoft....@dmarc.ietf.org> wrote: >>>> >>>>> During today’s call, it was asked whether we should drop the OAuth 2.0 >>>>> language that: >>>>> >>>>> The client MUST NOT use the authorization code >>>>> >>>>> more than once. If an authorization code is used more than >>>>> >>>>> once, the authorization server MUST deny the request and >>>>> SHOULD >>>>> >>>>> revoke (when possible) all tokens previously issued based on >>>>> >>>>> that authorization code.” >>>>> >>>>> >>>>> >>>>> The rationale given was that enforcing one-time use is impractical in >>>>> distributed authorization server deployments. >>>>> >>>>> >>>>> >>>>> Thinking about this some more, at most, we should relax this to: >>>>> >>>>> The client MUST NOT use the authorization code >>>>> >>>>> more than once. If an authorization code is used more than >>>>> >>>>> once, the authorization server SHOULD deny the request and >>>>> SHOULD >>>>> >>>>> revoke (when possible) all tokens previously issued based on >>>>> >>>>> that authorization code.” >>>>> >>>>> >>>>> >>>>> In short, it should remain illegal for the client to try to reuse the >>>>> authorization code. We can relax the MUST to SHOULD in the server >>>>> requirements in recognition of the difficulty of enforcing the MUST. >>>>> >>>>> >>>>> >>>>> Code reuse is part of some attack scenarios. We must not sanction it. >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe >>> <https://preferences.forgerock.com/> >>> >>> _______________________________________________ >> 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
