PKCE is built in to the authorization code flow in OAuth 2.1 and does not depend on the client type.
Neil does bring up a good point about the "plain" challenge type though. The "plain" type does undermine some of the security guarantees that PKCE provides. The Security BCP does recommend against using the "plain" type but that may not be enough confidence to rely on this mechanism and give up others. Aaron On Wed, Oct 13, 2021 at 11:02 AM Warren Parad <wpa...@rhosys.ch> 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
