Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

[Jeff Craig <[e-mail]>]

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=
[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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=
>> [e-mail]> 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=
>>> [e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe
>> <https://preferences.forgerock.com/>
>>
>> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>