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
