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

From: Mike Jones <[email-masked]>
Date: Wed, 13 Oct 2021 17:16:17 +0000

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

---

From: Warren Parad <[email-masked]>
Date: Wed, 13 Oct 2021 19:27:03 +0200

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=
[email-masked]> wrote:

> During today’s call, it was asked whether we should drop the OAuth 2.0
> language that:
>
>          that authorization code.”
>
>
>
> The rationale given was that enforcing one-time use is impractical in
> distributed authorization server deployments.
>
>
>
>          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.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 13 Oct 2021 10:40:23 -0700

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=
[email-masked]> wrote:

> 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,
>> 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.
>
>

---

From: Neil Madden <[email-masked]>
Date: Wed, 13 Oct 2021 18:59:46 +0100

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 <[email-masked]> 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=[email-masked]> 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.
>> 
>> 
>>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones <Michael.Jones=[email-masked]> wrote:
>>> During today’s call, it was asked whether we should drop the OAuth 2.0 language that:
>>> 

-- 
Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe 
<https://preferences.forgerock.com/>

---

From: Warren Parad <[email-masked]>
Date: Wed, 13 Oct 2021 20:02:37 +0200

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

On Wed, Oct 13, 2021 at 7:59 PM Neil Madden <[email-masked]>
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
>
> 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
>> 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

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 13 Oct 2021 11:13:30 -0700

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 <[email-masked]> 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

---

From: Jeff Craig <[email-masked]>
Date: Wed, 13 Oct 2021 13:14:42 -0500

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).

---

From: Warren Parad <[email-masked]>
Date: Wed, 13 Oct 2021 20:18:16 +0200

(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

On Wed, Oct 13, 2021 at 8:15 PM Jeff Craig <jeffcraig=
[email-masked]> wrote:

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

---

From: David Waite <[email-masked]>
Date: Wed, 13 Oct 2021 12:31:42 -0600

I agree that PKCE (with a non-plain operational mode) protects the code from attacker use by the security BCP model (but not necessarily stronger models)

Would the prevalence for ASs which cannot enforce an atomic code grant warrant further language against plain PKCE?

-DW

> On Oct 13, 2021, at 11:16 AM, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 13 Oct 2021 18:40:20 +0000

There are legitimate use cases for a client to replay an authorization code. Connection failures happen. Servers fall over before completing requests. Users hit browser refresh buttons. Permitting replay of authorization codes (assuming valid PKCE, client creds, etc.) allows clients to handle these failure modes simply and gracefully via retries.

What is the practical reason for allowing "plain" PKCE in OAuth 2.1? Are there really use cases out there where SHA-256 is a deal breaker?

—
Annabelle Backman (she/her)
[email-masked]<mailto:[email-masked]>

On Oct 13, 2021, at 11:31 AM, David Waite <david=[email-masked]<mailto:david=[email-masked]>> wrote:

-DW

On Oct 13, 2021, at 11:16 AM, Mike Jones <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>> wrote:

                                                          -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Pieter Kasselman <[email-masked]>
Date: Wed, 13 Oct 2021 20:25:16 +0000

Aaron, I was curious what prevents an attacker from presenting an Authorization Code and a PKCE Code Verifier for a second time if the one time use requirement is removed. Is there another countermeasure in  PKCE that would prevent it? For example, an attacker may obtain the Authorization Code and the Code Verifier from a log and replay it.

Cheers

Pieter

From: OAuth <[email-masked]> On Behalf Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad <wparad=[email-masked]>
Cc: Mike Jones <Michael.Jones=[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

---
Aaron Parecki

On Wed, Oct 13, 2021 at 10:27 AM Warren Parad <wparad=[email-masked]<mailto:[email-masked]>> 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

Let's look at SHOULD

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788333255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lw%2BH1z1Ut9kr6S%2F4aVsPmcErAcZx0eK2WV78OlEl2dU%3D&reserved=0>.

On Wed, Oct 13, 2021 at 7:17 PM Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>> wrote:

                                                          -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788343208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ySJjihVbfLJJ85RtjNzEIMSPwe7kLZB8RKT8Ky3fYiA%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788343208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ySJjihVbfLJJ85RtjNzEIMSPwe7kLZB8RKT8Ky3fYiA%3D&reserved=0>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 13 Oct 2021 13:30:36 -0700

Aside from the "plain" method, the PKCE code verifier never leaves the
client until it's sent along with the authorization code in the POST
request to the token endpoint. The only place it can leak at that point is
if the authorization server itself leaks it. If you have things leaking
from the authorization server log, you likely have much bigger problems
than authorization code replays.

Keep in mind that even with the proposed change to drop the requirement of
authorization codes being one time use, authorization servers are free to
enforce this still if they want. Authorization code lifetimes are still
expected to be short lived as well.

Aaron

On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
[email-masked]> wrote:

> Aaron, I was curious what prevents an attacker from presenting an
> Authorization Code and a PKCE Code Verifier for a second time if the one
> time use requirement is removed. Is there another countermeasure in  PKCE
> that would prevent it? For example, an attacker may obtain the
> Authorization Code and the Code Verifier from a log and replay it.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Aaron Parecki
> *Sent:* Wednesday 13 October 2021 18:40
> *To:* Warren Parad <wparad=[email-masked]>
> *Cc:* Mike Jones <Michael.Jones=[email-masked]>;
> [email-masked]
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth
> 2.1
>
>
>
> *Warren Parad*
> Authress
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788333255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lw%2BH1z1Ut9kr6S%2F4aVsPmcErAcZx0eK2WV78OlEl2dU%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788343208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ySJjihVbfLJJ85RtjNzEIMSPwe7kLZB8RKT8Ky3fYiA%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788343208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ySJjihVbfLJJ85RtjNzEIMSPwe7kLZB8RKT8Ky3fYiA%3D&reserved=0>
>
>

---

From: Warren Parad <[email-masked]>
Date: Wed, 13 Oct 2021 22:36:12 +0200

I feel like I'm missing something, what stops just plain old network
sniffing and replying the whole encrypted payload to the AS and getting
back a valid token?

Warren Parad

Founder, CTO

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 13 Oct 2021 13:37:01 -0700

HTTPS, because if that's broken then the rest of OAuth falls apart too.

On Wed, Oct 13, 2021 at 1:36 PM Warren Parad <[email-masked]> wrote:

>> Keep in mind that even with the proposed change to drop the requirement
>> of authorization codes being one time use, authorization servers are free
>> to enforce this still if they want. Authorization code lifetimes are still

---

From: Sascha Preibisch <[email-masked]>
Date: Wed, 13 Oct 2021 13:50:02 -0700

If the challenge is based on distributed authorization server
configurations, how would they handle PKCE? I imagine that managing the
state for PKCE is not less challenging than managing authorization codes on
the server side, preventing reuse of them.
With that in mind I am not sure if I follow the given argument. I would
prefer to keep MUST as it is today.

On Wed, 13 Oct 2021 at 13:37, Aaron Parecki <[email-masked]> wrote:

>>>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and
>>>> OAuth 2.1
>>>>
>>>>
>>>>
>>>> The issue that was discussed is that using PKCE already provides all
>>>> the security benefit that is gained by enforcing single-use authorization
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>

---

From: Warren Parad <[email-masked]>
Date: Wed, 13 Oct 2021 22:52:23 +0200

The argument is "let's not have a requirement that doesn't serve to
increase security". If we can't think of a reason why it's necessary or
some attack it prevents against, it's better to allow AS to decide, rather
than forcing an unnecessary implementation detail.

Warren Parad

Founder, CTO

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 13 Oct 2021 13:56:18 -0700

The PKCE spec actually says "Typically, the "code_challenge" and
"code_challenge_method" values are stored in encrypted form in the "code"
itself" which I feel like might be a stretch to say that's typical, but
this scenario was clearly thought of ahead of time. Doing that would enable
an AS to avoid storing server-side state.

---

From: Sascha Preibisch <[email-masked]>
Date: Wed, 13 Oct 2021 14:06:22 -0700

Ok, if the goal is to avoid unnecessary requirements I am suggesting to
point out why MUST was changed to SHOULD. Otherwise developers will start
to mix and match OAuth 2.0 and OAuth 2.1 requirements as they see them fit
their needs.
In regards to encrypted values in PKCE, Aaron, I can also not confirm that
as the general implementation.

On Wed, 13 Oct 2021 at 13:56, Aaron Parecki <[email-masked]> wrote:

> On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <
> [email-masked]> wrote:
>
>>>>> Keep in mind that even with the proposed change to drop the
>>>>> requirement of authorization codes being one time use, authorization
>>>>> servers are free to enforce this still if they want. Authorization code
>>>>> lifetimes are still expected to be short lived as well.
>>>>>
>>>>> Aaron
>>>>>
>>>>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 13 Oct 2021 21:12:47 +0000

Even a distributed system with server-side state can still encounter challenges maintaining one-time usage, particularly if server-side state itself is distributed and eventually consistent. Given all the redirects and user actions in OAuth 2.0, a storage layer may reach consistency fast enough for the protocol to work while still being slow enough to leave open a window of replay opportunity.

—

On Oct 13, 2021, at 1:56 PM, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

The PKCE spec actually says "Typically, the "code_challenge" and "code_challenge_method" values are stored in encrypted form in the "code" itself" which I feel like might be a stretch to say that's typical, but this scenario was clearly thought of ahead of time. Doing that would enable an AS to avoid storing server-side state.

On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <[email-masked]<mailto:[email-masked]>> wrote:
If the challenge is based on distributed authorization server configurations, how would they handle PKCE? I imagine that managing the state for PKCE is not less challenging than managing authorization codes on the server side, preventing reuse of them.
With that in mind I am not sure if I follow the given argument. I would prefer to keep MUST as it is today.

On Wed, 13 Oct 2021 at 13:37, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:
HTTPS, because if that's broken then the rest of OAuth falls apart too.

On Wed, Oct 13, 2021 at 1:36 PM Warren Parad <[email-masked]<mailto:[email-masked]>> wrote:
I feel like I'm missing something, what stops just plain old network sniffing and replying the whole encrypted payload to the AS and getting back a valid token?

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 10:33 PM Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:
Aside from the "plain" method, the PKCE code verifier never leaves the client until it's sent along with the authorization code in the POST request to the token endpoint. The only place it can leak at that point is if the authorization server itself leaks it. If you have things leaking from the authorization server log, you likely have much bigger problems than authorization code replays.

Keep in mind that even with the proposed change to drop the requirement of authorization codes being one time use, authorization servers are free to enforce this still if they want. Authorization code lifetimes are still expected to be short lived as well.

Aaron

On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <[email-masked]<mailto:[email-masked]>> wrote:
Aaron, I was curious what prevents an attacker from presenting an Authorization Code and a PKCE Code Verifier for a second time if the one time use requirement is removed. Is there another countermeasure in  PKCE that would prevent it? For example, an attacker may obtain the Authorization Code and the Code Verifier from a log and replay it.

Cheers

Pieter

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad <wparad=[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

---
Aaron Parecki

Let's look at SHOULD

Warren Parad
Founder, CTO

                                                          -- Mike

---

From: Pieter Kasselman <[email-masked]>
Date: Wed, 13 Oct 2021 21:15:43 +0000

Log files can exist in lots of place (clients, servers, data lakes). The question is whether it is a valid assumption that an attacker cannot obtain an Authorization Code and a Code Verifier and present it a second time round. Limiting the validity period is one layer of defence, PKCE is another layer, one time use enforcement is another. Assuming breach and designing from a defence in depth perspective is a good practice, so why not give implementors options (and guidance) to add additional layers of defence to match their risk profiles?

From: OAuth <[email-masked]> On Behalf Of Sascha Preibisch
Sent: Wednesday 13 October 2021 22:06
To: Aaron Parecki <[email-masked]>
Cc: IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Ok, if the goal is to avoid unnecessary requirements I am suggesting to point out why MUST was changed to SHOULD. Otherwise developers will start to mix and match OAuth 2.0 and OAuth 2.1 requirements as they see them fit their needs.
In regards to encrypted values in PKCE, Aaron, I can also not confirm that as the general implementation.

On Wed, 13 Oct 2021 at 13:56, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:
The PKCE spec actually says "Typically, the "code_challenge" and "code_challenge_method" values are stored in encrypted form in the "code" itself" which I feel like might be a stretch to say that's typical, but this scenario was clearly thought of ahead of time. Doing that would enable an AS to avoid storing server-side state.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293904430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vwcfj%2FVB8a84yDoAmqkXraWyqjOfWGrV08XdtZLWMXw%3D&reserved=0>.

Aaron

Cheers

Pieter

---
Aaron Parecki

Let's look at SHOULD

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9LtSUyb7WjZQqY%2FBnFy47HxchMNGZG6Qx82hj%2Bd9X04%3D&reserved=0>.

                                                          -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gWX04yAEt3IP7lWFDS0zBzyJN8nvNfEf6Eq7i6qU7fM%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%3D&reserved=0>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 13 Oct 2021 14:35:34 -0700

Yes, as I said before, authorization servers are free to enforce one-time
use of the authorization code even if there isn't a requirement to. The
proposal is just to remove the *requirement* of authorization servers
enforcing it.

I am okay with Mike's suggestion of changing the language to "SHOULD" to
continue to point out the possibility of enforcing one-time authorization
codes if desired.

On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman <
[email-masked]> wrote:

> Log files can exist in lots of place (clients, servers, data lakes). The
> question is whether it is a valid assumption that an attacker cannot obtain
> an Authorization Code and a Code Verifier and present it a second time
> round. Limiting the validity period is one layer of defence, PKCE is
> another layer, one time use enforcement is another. Assuming breach and
> designing from a defence in depth perspective is a good practice, so why
> not give implementors options (and guidance) to add additional layers of
> defence to match their risk profiles?
>
>
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Sascha Preibisch
> *Sent:* Wednesday 13 October 2021 22:06
> *To:* Aaron Parecki <[email-masked]>
> *Cc:* IETF oauth WG <[email-masked]>
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293904430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vwcfj%2FVB8a84yDoAmqkXraWyqjOfWGrV08XdtZLWMXw%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9LtSUyb7WjZQqY%2FBnFy47HxchMNGZG6Qx82hj%2Bd9X04%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gWX04yAEt3IP7lWFDS0zBzyJN8nvNfEf6Eq7i6qU7fM%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%3D&reserved=0>
>
>

---

From: Ash Narayanan <[email-masked]>
Date: Fri, 15 Oct 2021 11:50:43 +1100

> proposal is just to remove the *requirement* of authorization servers

I agree, and therefore I think what it really ought to be is "MAY".

Annabelle said:

> There are legitimate use cases for a client to replay an authorization
> code. Connection failures happen. Servers fall over before completing
> requests. Users hit browser refresh buttons. Permitting replay of
> authorization codes (assuming valid PKCE, client creds, etc.) allows
> clients to handle these failure modes simply and gracefully via retries.

Couldn't agree more. Having experienced these exact use-cases, I can
honestly say that denying users a smooth experience just to be compliant
with the spec, which offers no additional security if PKCE is also being
used, makes no sense.
It is also more effort (from a repository layer perspective) to implement
one-time use than do PKCE verification.

What is the practical reason for allowing "plain" PKCE in OAuth 2.1? Are
> there really use cases out there where SHA-256 is a deal breaker?
>

I'd be interested in these use-cases as well (I can't think of any).

---

From: Pieter Kasselman <[email-masked]>
Date: Fri, 15 Oct 2021 08:16:59 +0000

Any weakening of the requirement should include a clear outline of the risks to help implementors make informed decisions.

From: OAuth <[email-masked]> On Behalf Of Ash Narayanan
Sent: Friday 15 October 2021 01:51
To: Aaron Parecki <[email-masked]>
Cc: IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

You don't often get email from [email-masked]. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
Yes, as I said before, authorization servers are free to enforce one-time use of the authorization code even if there isn't a requirement to. The proposal is just to remove the *requirement* of authorization servers enforcing it.

Annabelle said:

Couldn't agree more. Having experienced these exact use-cases, I can honestly say that denying users a smooth experience just to be compliant with the spec, which offers no additional security if PKCE is also being used, makes no sense.
It is also more effort (from a repository layer perspective) to implement one-time use than do PKCE verification.

On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:
Yes, as I said before, authorization servers are free to enforce one-time use of the authorization code even if there isn't a requirement to. The proposal is just to remove the *requirement* of authorization servers enforcing it.

I am okay with Mike's suggestion of changing the language to "SHOULD" to continue to point out the possibility of enforcing one-time authorization codes if desired.

On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman <[email-masked]<mailto:[email-masked]>> wrote:
Log files can exist in lots of place (clients, servers, data lakes). The question is whether it is a valid assumption that an attacker cannot obtain an Authorization Code and a Code Verifier and present it a second time round. Limiting the validity period is one layer of defence, PKCE is another layer, one time use enforcement is another. Assuming breach and designing from a defence in depth perspective is a good practice, so why not give implementors options (and guidance) to add additional layers of defence to match their risk profiles?

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Sascha Preibisch
Sent: Wednesday 13 October 2021 22:06
To: Aaron Parecki <[email-masked]<mailto:[email-masked]>>
Cc: IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871378875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q%2BVgxFWvU1T07%2FNrIriU3GsN5qRZjlnTWHyOYoaepbU%3D&reserved=0>.

Aaron

Cheers

Pieter

---
Aaron Parecki

Let's look at SHOULD

[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871388836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yJZ3n6X6%2BeVBK5KrHCNWREEX6NYMl3lqQxhW%2FjwguaQ%3D&reserved=0>.

                                                          -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871388836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ikRSMsY7goK%2FXMfhd43ClqNoQmhfAsq754MsS2uOFAg%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871398790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OY9y15o%2FBx7pcLWwrzcdvKvda7rW5mYcMAJAIVD2EzM%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871398790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OY9y15o%2FBx7pcLWwrzcdvKvda7rW5mYcMAJAIVD2EzM%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871398790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OY9y15o%2FBx7pcLWwrzcdvKvda7rW5mYcMAJAIVD2EzM%3D&reserved=0>

---

From: Warren Parad <[email-masked]>
Date: Fri, 15 Oct 2021 10:24:36 +0200

I wouldn't be against lowering it to MAY but only if we stipulate a SHOULD
on an expected lifetime of an authorization code. I think sending the
message that these should be one time use except in exceptional
circumstances.

Warren Parad

Founder, CTO

On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman <pieter.kasselman=
[email-masked]> wrote:

> Any weakening of the requirement should include a clear outline of the
> risks to help implementors make informed decisions.
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Ash Narayanan
> *Sent:* Friday 15 October 2021 01:51
> You don't often get email from [email-masked]. Learn why this
> is important <http://aka.ms/LearnAboutSenderIdentification>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871378875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q%2BVgxFWvU1T07%2FNrIriU3GsN5qRZjlnTWHyOYoaepbU%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871388836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yJZ3n6X6%2BeVBK5KrHCNWREEX6NYMl3lqQxhW%2FjwguaQ%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871388836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ikRSMsY7goK%2FXMfhd43ClqNoQmhfAsq754MsS2uOFAg%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871398790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OY9y15o%2FBx7pcLWwrzcdvKvda7rW5mYcMAJAIVD2EzM%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871398790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OY9y15o%2FBx7pcLWwrzcdvKvda7rW5mYcMAJAIVD2EzM%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C36e879a0ca5e4defdda108d98f75e61d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698558871398790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OY9y15o%2FBx7pcLWwrzcdvKvda7rW5mYcMAJAIVD2EzM%3D&reserved=0>
>

---

From: Pieter Kasselman <[email-masked]>
Date: Fri, 15 Oct 2021 09:04:38 +0000

SHOULD is more likely to cause the right conversations to take place for implementors as they weigh the risks. Reducing it to MAY risks diluting it too much.

From: OAuth <[email-masked]> On Behalf Of Warren Parad
Sent: Friday 15 October 2021 09:25
To: Pieter Kasselman <pieter.kasselman=[email-masked]>
Cc: IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

I wouldn't be against lowering it to MAY but only if we stipulate a SHOULD on an expected lifetime of an authorization code. I think sending the message that these should be one time use except in exceptional circumstances.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154740432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6rSI2UvnakrWNh3qtBEgIMbRO8L9oXu8zGj4Fd128B8%3D&reserved=0>.

On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman <pieter.kasselman=[email-masked]<mailto:[email-masked]>> wrote:
Any weakening of the requirement should include a clear outline of the risks to help implementors make informed decisions.

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Ash Narayanan

You don't often get email from [email-masked]<mailto:[email-masked]>. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
Yes, as I said before, authorization servers are free to enforce one-time use of the authorization code even if there isn't a requirement to. The proposal is just to remove the *requirement* of authorization servers enforcing it.

Annabelle said:

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154750385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y86Gy8RiRIbIAW3So8hr4PxYsta1VWX1X7l%2FHzVbcvI%3D&reserved=0>.

Aaron

Cheers

Pieter

---
Aaron Parecki

Let's look at SHOULD

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lbb9cJl0VUcfBD9IwzKF4BeB5nnggZxLB1TwlZYdNK4%3D&reserved=0>.

                                                          -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u3yNDEeIsFvqGwu3x8%2F22D25o3bVO9PkrBEA2IEKSzY%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>

---

From: Daniel Fett <[email-masked]>
Date: Fri, 15 Oct 2021 17:12:33 +0200

I don't think that a MAY is appropriate here.

I wasn't in the call yesterday, so I hope I don't miss anything here, but...

Even with PKCE, the one-time use requirement of the code is still
important. First and foremost, if we allow unlimited re-use of the same
code, even just as an option, we change the semantics of this artifact.
I guess there are many examples where this causes issues, but one would
be DPoP. It assumes that there is only one (successful) token request
and in that request, the token is bound to a specific key. If there can
be more than one successful token request, all it takes is
code_challenge and the code sitting around somewhere in accessible
memory and an XSS attacker can exfiltrate them and use them on his own
device, binding the resulting token to an attacker-controlled key. This
is the attack outcome against which we introduced the nonce in DPoP.
(Probably we should add this thought as a security consideration to
DPoP, but that is a different topic.) I guess we can come up with many
other mechanisms and mitigations that depend on code being one-time use.

The attack described also shows nicely that code replay protection and
PKCE serve similar purposes, but are not the same thing.

The Security BCP introduces a second layer of defense at pretty much all
the critical places in the protocol, because practice shows that a
single defense can break too easily. For example, an attacker with
read-only access to the token request would be pretty bad without code
replay protections in place. Such attackers are considered in FAPI.
(Somebody capable of reading system logs at the client or server, proxy
logs at the client or server, browser logs, etc.)

Therefore, in my opinion, the code MUST be short-lived and at least
SHOULD, better MUST be one-time use.

And ideally, the code SHOULD also be invalidated if the PKCE verifier
does not match, not sure if that is in the current text or not.

-Daniel

Am 15.10.21 um 11:04 schrieb Pieter Kasselman:
>
> SHOULD is more likely to cause the right conversations to take place
> for implementors as they weigh the risks. Reducing it to MAY risks
> diluting it too much.
>
>  
>
> *From:*OAuth <[email-masked]> *On Behalf Of *Warren Parad
> *Sent:* Friday 15 October 2021 09:25
> *To:* Pieter Kasselman <pieter.kasselman=[email-masked]>
> I wouldn't be against lowering it to MAY but only if we stipulate a
> SHOULD on an expected lifetime of an authorization code. I think
> sending the message that these should be one time use except in
> exceptional circumstances.
>
>
> 	
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service.
> Implement Authress
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154740432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6rSI2UvnakrWNh3qtBEgIMbRO8L9oXu8zGj4Fd128B8%3D&reserved=0>.
>
>  
>
>  
>
> On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman
> <pieter.kasselman=[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Any weakening of the requirement should include a clear outline of
>     the risks to help implementors make informed decisions.
>
>      
>
>     *From:*OAuth <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Ash Narayanan
>     *To:* Aaron Parecki <[email-masked] <mailto:[email-masked]>>
>     *Cc:* IETF oauth WG <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse
>     and OAuth 2.1
>
>      
>
>
>     	
>
>     You don't often get email from [email-masked]
>     <mailto:[email-masked]>. Learn why this is important
>     <http://aka.ms/LearnAboutSenderIdentification>
>
>     	
>
>         Yes, as I said before, authorization servers are free to
>         enforce one-time use of the authorization code even if there
>         isn't a requirement to. The proposal is just to remove the
>         *requirement* of authorization servers enforcing it.
>
>      
>
>         There are legitimate use cases for a client to replay an
>         authorization code. Connection failures happen. Servers fall
>         over before completing requests. Users hit browser refresh
>         buttons. Permitting replay of authorization codes (assuming
>         valid PKCE, client creds, etc.) allows clients to handle these
>         failure modes simply and gracefully via retries.
>
>      
>
>     Couldn't agree more. Having experienced these exact use-cases, I
>     can honestly say that denying users a smooth experience just to be
>     compliant with the spec, which offers no additional security if
>     PKCE is also being used, makes no sense.
>
>     It is also more effort (from a repository layer perspective) to
>     implement one-time use than do PKCE verification.
>
>      
>
>         What is the practical reason for allowing "plain" PKCE in
>         OAuth 2.1? Are there really use cases out there where SHA-256
>         is a deal breaker?
>
>      
>
>         Yes, as I said before, authorization servers are free to
>         enforce one-time use of the authorization code even if there
>         isn't a requirement to. The proposal is just to remove the
>         *requirement* of authorization servers enforcing it.
>
>          
>
>         I am okay with Mike's suggestion of changing the language to
>         "SHOULD" to continue to point out the possibility of enforcing
>         one-time authorization codes if desired.
>
>          
>
>          
>
>          
>
>         On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Log files can exist in lots of place (clients, servers,
>             data lakes). The question is whether it is a valid
>             assumption that an attacker cannot obtain an Authorization
>             Code and a Code Verifier and present it a second time
>             round. Limiting the validity period is one layer of
>             defence, PKCE is another layer, one time use enforcement
>             is another. Assuming breach and designing from a defence
>             in depth perspective is a good practice, so why not give
>             implementors options (and guidance) to add additional
>             layers of defence to match their risk profiles?  
>
>              
>
>              
>
>             *From:*OAuth <[email-masked]
>             <mailto:[email-masked]>> *On Behalf Of *Sascha
>             Preibisch
>             *To:* Aaron Parecki <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:* IETF oauth WG <[email-masked] <mailto:[email-masked]>>
>             *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization
>             code reuse and OAuth 2.1
>
>              
>
>             Ok, if the goal is to avoid unnecessary requirements I am
>             suggesting to point out why MUST was changed to SHOULD.
>             Otherwise developers will start to mix and match OAuth 2.0
>             and OAuth 2.1 requirements as they see them fit their needs.
>
>             In regards to encrypted values in PKCE, Aaron, I can also
>             not confirm that as the general implementation.
>
>              
>
>             On Wed, 13 Oct 2021 at 13:56, Aaron Parecki
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 The PKCE spec actually says "Typically, the
>                 "code_challenge" and "code_challenge_method" values
>                 are stored in encrypted form in the "code" itself"
>                 which I feel like might be a stretch to say that's
>                 typical, but this scenario was clearly thought of
>                 ahead of time. Doing that would enable an AS to avoid
>                 storing server-side state.
>
>                  
>
>                 On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                     If the challenge is based on
>                     distributed authorization server configurations,
>                     how would they handle PKCE? I imagine that
>                     managing the state for PKCE is not less
>                     challenging than managing authorization codes on
>                     With that in mind I am not sure if I follow the
>                     given argument. I would prefer to keep MUST as it
>                     is today.
>
>                      
>
>                      
>
>                     On Wed, 13 Oct 2021 at 13:37, Aaron Parecki
>                     <[email-masked] <mailto:[email-masked]>> wrote:
>
>                         On Wed, Oct 13, 2021 at 1:36 PM Warren Parad
>                         <[email-masked] <mailto:[email-masked]>>
>                         wrote:
>
>                             I feel like I'm missing something, what
>                             stops just plain old network sniffing and
>                             replying the whole encrypted payload to
>                             the AS and getting back a valid token?
>
>
>                             Image removed by sender.
>
>                             	
>
>                             *Warren Parad*
>
>                             Founder, CTO
>
>                             Secure your user data with IAM
>                             authorization as a service.
>                             Implement Authress
>                             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154750385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y86Gy8RiRIbIAW3So8hr4PxYsta1VWX1X7l%2FHzVbcvI%3D&reserved=0>.
>
>                              
>
>                              
>
>                             On Wed, Oct 13, 2021 at 10:33 PM Aaron
>                             Parecki <[email-masked]
>                             <mailto:[email-masked]>> wrote:
>
>                                 client until it's sent along with the
>                                 authorization code in the POST request
>                                 to the token endpoint. The only place
>                                 it can leak at that point is if the
>                                 authorization server itself leaks it.
>                                 If you have things leaking from the
>                                 authorization server log, you likely
>                                 have much bigger problems than
>                                 authorization code replays.
>
>                                  
>
>                                 On Wed, Oct 13, 2021 at 1:25 PM Pieter
>                                 Kasselman
>                                 <[email-masked]
>                                 <mailto:[email-masked]>>
>                                 wrote:
>
>                                     Authorization Code and a PKCE Code
>                                     Verifier for a second time if the
>                                     one time use requirement is
>                                     removed. Is there another
>                                     countermeasure in  PKCE that would
>                                     prevent it? For example, an
>                                     attacker may obtain the
>                                     *From:*OAuth
>                                     <[email-masked]
>                                     <mailto:[email-masked]>>
>                                     *On Behalf Of *Aaron Parecki
>                                     *To:* Warren Parad
>                                     <wparad=[email-masked]
>                                     <mailto:[email-masked]>>
>                                     *Cc:* Mike Jones
>                                     <Michael.Jones=[email-masked]
>                                     <mailto:[email-masked]>>;
>                                     [email-masked] <mailto:[email-masked]>
>                                     *Subject:* [EXTERNAL] Re:
>                                     [OAUTH-WG] Authorization code
>                                     reuse and OAuth 2.1
>
>                                      
>
>                                     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.
>
>                                      
>
>                                     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=[email-masked]
>                                     <mailto:[email-masked]>>
>                                     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"?
>
>                                          
>
>                                         Image removed by sender.
>
>                                         	
>
>                                         *Warren Parad*
>
>                                         Founder, CTO
>
>                                         Secure your user data with IAM
>                                         authorization as a service.
>                                         Implement Authress
>                                         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lbb9cJl0VUcfBD9IwzKF4BeB5nnggZxLB1TwlZYdNK4%3D&reserved=0>.
>
>                                          
>
>                                          
>
>                                         On Wed, Oct 13, 2021 at 7:17
>                                         PM Mike Jones
>                                         <Michael.Jones=[email-masked]
>                                         <mailto:[email-masked]>>
>                                         wrote:
>
>                                             During today’s call, it
>                                             was asked whether we
>                                             should drop the OAuth 2.0
>                                             language that:
>
>                                                      The client MUST
>                                                      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
>                                             Thinking about this some
>                                             more, at most, we should
>                                             relax this to:
>                                                      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
>
>                                              
>
>                                             <mailto:[email-masked]>
>                                             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u3yNDEeIsFvqGwu3x8%2F22D25o3bVO9PkrBEA2IEKSzY%3D&reserved=0>
>
>                                         <mailto:[email-masked]>
>                                         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
>
>                         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
>
>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
>

-- 
https://danielfett.de

---

From: Takahiko Kawasaki <[email-masked]>
Date: Mon, 18 Oct 2021 09:40:29 +0900

Allowing to specify the same authorization code for retrial due to network
failure is different from allowing reuse of successfully-consumed
authorization code. They should not be mixed. The former is acceptable, but
the latter should be prohibited.

The difference between (1) reuse of authorization code and (2) reuse of
successfully-consumed authorization code is important for discussion.

Taka

On Sat, Oct 16, 2021 at 12:13 AM Daniel Fett <[email-masked]> wrote:

> code, even just as an option, we change the semantics of this artifact. I
> guess there are many examples where this causes issues, but one would be
> DPoP. It assumes that there is only one (successful) token request and in
> that request, the token is bound to a specific key. If there can be more
> than one successful token request, all it takes is code_challenge and the
> code sitting around somewhere in accessible memory and an XSS attacker can
> exfiltrate them and use them on his own device, binding the resulting token
> to an attacker-controlled key. This is the attack outcome against which we
> introduced the nonce in DPoP. (Probably we should add this thought as a
> security consideration to DPoP, but that is a different topic.) I guess we
> can come up with many other mechanisms and mitigations that depend on code
> being one-time use.
>
> the critical places in the protocol, because practice shows that a single
> defense can break too easily. For example, an attacker with read-only
> access to the token request would be pretty bad without code replay
> protections in place. Such attackers are considered in FAPI. (Somebody
> capable of reading system logs at the client or server, proxy logs at the
> client or server, browser logs, etc.)
>
> And ideally, the code SHOULD also be invalidated if the PKCE verifier does
> not match, not sure if that is in the current text or not.
>
> -Daniel
>
>
>
> SHOULD is more likely to cause the right conversations to take place for
> implementors as they weigh the risks. Reducing it to MAY risks diluting it
> too much.
>
>
>
> *From:* OAuth <[email-masked]> <[email-masked]> *On
> Behalf Of *Warren Parad
> <pieter.kasselman=[email-masked]>
> *Cc:* IETF oauth WG <[email-masked]> <[email-masked]>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> -- https://danielfett.de
>

---

From: Warren Parad <[email-masked]>
Date: Mon, 18 Oct 2021 10:08:51 +0200

I don't think those cases can be distinguished it practice, which is both
the point of the discussion and the differencing of opinion on how to
handle this.

To whom is the question. If the AS thinks that it isn't used yet, then it
isn't reuse. If the AS thinks it is used but the client doesn't this is the
case we are talking about. The auth code has been completed by the AS but
the client failed to continue, either it was never successfully received
due to a network error or processing on the client side failed. No reason
to unnecessarily punish the user.

To infer from your comment, you mean for the current wording to stay
exactly as is without change, is that correct, or did I miss a key point?

On Mon, Oct 18, 2021, 02:41 Takahiko Kawasaki <[email-masked]> wrote:

>> SHOULD on an expected lifetime of an authorization code. I think sending
>> the message that these should be one time use except in exceptional
>> circumstances.
>>
>>
>> *Warren Parad*
>>
>> Founder, CTO
>>

---

From: Warren Parad <[email-masked]>
Date: Wed, 20 Oct 2021 10:47:47 +0200

There is a pattern, where a user configures one credentialed entity for
access to a RS, but controls neither the credentialed entity nor the RS. I
might say technically the user is acting as the AS, but it isn't clear to
me.

Concretely, CI/CD services such as GitHub and GitLab support runners that
come with a JWT, whom this JWT should be issued to is not exactly clear.
These tokens are intended to be used with third party RS such as AWS IAM to
authenticate and access resources in AWS. (AWS reference
<https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html>
)

Currently, GitLab is prototyping support for this access and wants to know
what's a good meaningful value for the AUD to be. (GitLab context
<https://gitlab.com/gitlab-org/gitlab/-/issues/216259#note_708055501>)

Personally, while I'm able to specify who is the client, RS, and AS, it
doesn't feel exactly like it's something directly supported by any RFC, but
it does seem like it should be. (AWS = RS, gitlab job = user, gitlab server
= AS)

Due to the nature of what's available for configuration on both sides, it's
likely they want to go with altering the AUD to point itself at the git
repository url where the token comes from rather than the RS which would
like be the AWS account. The closing thought I have is if we suspend for
one moment expectations about who is authorization by whom, it's possible
to also see that AWS is the AS, and the gitlab runner is a client using the
jwt-bearer credentials grant.

Is there anyone that wants to weigh in on this, it's a potentially great
opportunity to drive the right practice at the right time.

(I'm happy to relay any outcome back to the thread or feel free to post
directly on the Gitlab issue
<https://gitlab.com/gitlab-org/gitlab/-/issues/216259#note_708055501>.

- Warren

Warren Parad

Founder, CTO

---

From: Ash Narayanan <[email-masked]>
Date: Thu, 21 Oct 2021 09:52:30 +1100

Hm, interesting Warren.
AWS feels like both the AS and RS in this scenario; I don’t see any reason why these have to be separate entities.

> 
> On 20 Oct 2021, at 7:48 pm, Warren Parad <wparad=[email-masked]> wrote:
> 
> 
> There is a pattern, where a user configures one credentialed entity for access to a RS, but controls neither the credentialed entity nor the RS. I might say technically the user is acting as the AS, but it isn't clear to me.
> 
> Concretely, CI/CD services such as GitHub and GitLab support runners that come with a JWT, whom this JWT should be issued to is not exactly clear. These tokens are intended to be used with third party RS such as AWS IAM to authenticate and access resources in AWS. (AWS reference)
> 
> Currently, GitLab is prototyping support for this access and wants to know what's a good meaningful value for the AUD to be. (GitLab context)
> 
> Personally, while I'm able to specify who is the client, RS, and AS, it doesn't feel exactly like it's something directly supported by any RFC, but it does seem like it should be. (AWS = RS, gitlab job = user, gitlab server = AS)
> 
> Due to the nature of what's available for configuration on both sides, it's likely they want to go with altering the AUD to point itself at the git repository url where the token comes from rather than the RS which would like be the AWS account. The closing thought I have is if we suspend for one moment expectations about who is authorization by whom, it's possible to also see that AWS is the AS, and the gitlab runner is a client using the jwt-bearer credentials grant.
> 
> Is there anyone that wants to weigh in on this, it's a potentially great opportunity to drive the right practice at the right time.
> 
> (I'm happy to relay any outcome back to the thread or feel free to post directly on the Gitlab issue.
> 
> - Warren
> 
> 
> Warren Parad
> Founder, CTO