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

[Warren Parad <[e-mail]>]

(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=
[e-mail]> 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=
> [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
>>
>