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

[Warren Parad <[e-mail]>]

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/>
>
>