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

From: Mike Jones <[email-masked]>
Date: Fri, 15 Oct 2021 23:41:26 +0000

As I see it, the retry in case of network failures should happen by performing a new authorization request – not by trying to reuse an authorization code – which is indistinguishable from an attack.

Let’s not use OAuth 2.1 as an opportunity to sanction behaviors that we can’t distinguish from attacks.

The prohibition on clients reusing an authorization code needs to remain.

                                                          -- Mike

From: Vittorio Bertocci <Vittorio=[email-masked]>
Sent: Friday, October 15, 2021 4:19 PM
To: Richard Backman, Annabelle <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

I am a fan of this approach. It feels pretty empty to cast people out of compliance just because they are handling a realistic circumstance, such as network failures, that we know about beforehand.
In addition, this gives us a chance to provide guidance on how to handle the situation, instead of leaving AS implementers to their own device.

On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
    The client MUST NOT use the authorization code more than once.

This language makes it impossible to build a fault tolerant, spec compliant client, as it prohibits retries. We could discuss whether a retry really constitutes a separate "use", but ultimately it doesn't matter; multiple presentations of the same code look the same to the AS, whether they are the result of retries, the client attempting to get multiple sets of tokens, or an unauthorized party trying to replay the code.

I think we can have a fault tolerant, replay-proof implementation, but it takes some effort:

  1.  The AS can prevent the authorized client from using one code to get a bunch of independent refresh and access token pairs by either re-issuing the same token (effectively making the token request idempotent) or invalidating previously issued tokens for that code. (Almost but not quite idempotent…idempotent-adjacent?)
  2.  The AS can prevent unauthorized parties from replaying snooped codes+PKCE by requiring stronger client authentication: implement dynamic client registration and require a replay-resistant client authentication method like `jwt-bearer`. The AS can enforce one-time use of the client credential token without breaking fault tolerance, as the client can easily mint a new one for each retry to the token endpoint.

Yes, I know, this is way more complex than just a credential-less public client doing PKCE. Perhaps we can have our cake and eat it too with language like:

The client MUST NOT use the authorization code more than once, unless retrying a token request that failed for reasons beyond the scope of this protocol. (e.g., network interruption, server outage) Refer to [Fault Tolerant Replay Prevention] for guidance.

…where Fault Tolerant Replay Prevention is a subsection under Security Considerations. I don't think this wording is quite right, as the guidance is really going to be for the AS, not the client, but hopefully it's enough to get the idea across.

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

On Oct 15, 2021, at 8:27 AM, Mike Jones <Michael.Jones=[email-masked]<mailto:Michael.Jones=[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.

I agree with Daniel.

Also, while we’ve talked about server requirements, I think it’s equally important that we retain this client requirement:

    The client MUST NOT use the authorization code more than once.

                                                          -- Mike

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Daniel Fett
Sent: Friday, October 15, 2021 8:13 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Re: Authorization code reuse and OAuth 2.1

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]><mailto:[email-masked]> On Behalf Of Warren Parad
Sent: Friday 15 October 2021 09:25
To: Pieter Kasselman <pieter.kasselman=[email-masked]><mailto:pieter.kasselman=[email-masked]>
Cc: IETF oauth WG <[email-masked]><mailto:[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.

[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%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
Sent: Friday 15 October 2021 01:51
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.

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

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

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

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]<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"?

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

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

--

https://danielfett.de<https://danielfett.de/>
_______________________________________________
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: Ash Narayanan <[email-masked]>
Date: Sat, 16 Oct 2021 12:22:56 +1100

Fully support Annabelle's idea of idempotent tokens.
1. It makes sense (give me the same code/verifier, I'll give you back the
same tokens).
2. It negates the possible attack vectors mentioned by  Daniel.
3. It is easy to implement.

Regarding Mike's comments...

As I see it, the retry in case of network failures should happen by
> performing a new authorization request – not by trying to reuse an
> authorization code – which is indistinguishable from an attack.

This offers no additional security and creates a poor user experience. With
idempotent tokens, there is no incentive for the attacker to replay than to
just use the already generated tokens, which I assume the attacker would
have access to given they have access to the code/verifier.

Let’s not use OAuth 2.1 as an opportunity to sanction behaviors that we
> can’t distinguish from attacks.

I would argue that we should also take the opportunity to make Oauth2.1
more meaningful/easier to implement, by reducing unnecessary requirements
that offer no additional security.

Daniel did also mention this bit, which I agree with:

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

On Sat, Oct 16, 2021 at 10:42 AM Mike Jones <Michael.Jones=
> [email-masked]> wrote:
>
As I see it, the retry in case of network failures should happen by
> performing a new authorization request – not by trying to reuse an
> authorization code – which is indistinguishable from an attack.
>
>
>
> *From:* Vittorio Bertocci <Vittorio=[email-masked]>
> *Sent:* Friday, October 15, 2021 4:19 PM
> *To:* Richard Backman, Annabelle <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; [email-masked]
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth
> 2.1
>
>
>
> I am a fan of this approach. It feels pretty empty to cast people out of
> compliance just because they are handling a realistic circumstance, such as
> network failures, that we know about beforehand.
>
> In addition, this gives us a chance to provide guidance on how to handle
> the situation, instead of leaving AS implementers to their own device.
>
>
>
> On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle <richanna=
> [email-masked]> wrote:
>
> This language makes it impossible to build a fault tolerant, spec
> compliant client, as it prohibits retries. We could discuss whether a retry
> really constitutes a separate "use", but ultimately it doesn't matter;
> multiple presentations of the same code look the same to the AS, whether
> they are the result of retries, the client attempting to get multiple sets
> of tokens, or an unauthorized party trying to replay the code.
>
>
>
>    1. The AS can prevent the authorized client from using one code to get
>    a bunch of independent refresh and access token pairs by either re-issuing
>    the same token (effectively making the token request idempotent) or
>    invalidating previously issued tokens for that code. (Almost but not quite
>    idempotent…idempotent-adjacent?)
>    2. The AS can prevent unauthorized parties from replaying snooped
>    codes+PKCE by requiring stronger client authentication: implement dynamic
>    client registration and require a replay-resistant client authentication
>    method like `jwt-bearer`. The AS can enforce one-time use of the client
>    credential token without breaking fault tolerance, as the client can easily
>    mint a new one for each retry to the token endpoint.
>
>
>
> Yes, I know, this is way more complex than just a credential-less public
> client doing PKCE. Perhaps we can have our cake and eat it too with
> language like:
>
>
>
> The client MUST NOT use the authorization code more than once, unless
> retrying a token request that failed for reasons beyond the scope of this
> protocol. (e.g., network interruption, server outage) Refer to [Fault
> Tolerant Replay Prevention] for guidance.
>
>
>
> …where Fault Tolerant Replay Prevention is a subsection under Security
> Considerations. I don't think this wording is quite right, as the guidance
> is really going to be for the AS, not the client, but hopefully it's enough
> to get the idea across.
>
>
>
> —
>
> [email-masked]
> On Oct 15, 2021, at 8:27 AM, Mike Jones <
> Michael.Jones=[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.
>
>
>
> I agree with Daniel.
>
>
>
> Also, while we’ve talked about server requirements, I think it’s equally
> important that we retain this client requirement:
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Daniel Fett
> *Sent:* Friday, October 15, 2021 8:13 AM
> *To:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Re: Authorization code reuse and OAuth 2.1
>
>
>
> 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.)
>
>
>
> 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
> *Sent:* Friday 15 October 2021 09:25
> *To:* Pieter Kasselman <pieter.kasselman=[email-masked]>
> <pieter.kasselman=[email-masked]>
> *Cc:* IETF oauth WG <[email-masked]> <[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]> 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
> *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.
>
>
>
> 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.
>
> 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?
>
>
>
> On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki <[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]> 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
>
>
>
> 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.
>
> On Wed, 13 Oct 2021 at 13:56, Aaron Parecki <[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]> 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.
>
> On Wed, 13 Oct 2021 at 13:37, Aaron Parecki <[email-masked]> wrote:
>
> On Wed, Oct 13, 2021 at 1:36 PM Warren Parad <[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://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]> 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]> 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
>
>
>
> 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
> <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]> wrote:
>
> The rationale given was that enforcing one-time use is impractical in
> distributed authorization server deployments.
>
>
>
> 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.
>
>
>
> [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>
>
> [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>
>
> [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>
>
> [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%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
> [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%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
>
>
> [email-masked]
> https://danielfett.de
> [email-masked]
> [email-masked]
> [email-masked]

---

From: Vittorio Bertocci <[email-masked]>
Date: Fri, 15 Oct 2021 19:00:55 -0700

I see the formal reasoning behind the suggestion, and I agree it would be
the safest behavior, but I don’t think it’s a realistic expectation. The
end user experience necessary for obtaining a new authorization code (with
possible future complications if browsers start to see excess redirects
toward a domain as evidence of tracking and strip parameters out) and the
complexity of moving execution back from code to front channel as error
management IMO makes it very unlikely that developers would pursue that
approach (which I have never seen implemented in the wild).

---

From: David Waite <[email-masked]>
Date: Fri, 15 Oct 2021 20:05:57 -0600

> On Oct 15, 2021, at 7:23 PM, Ash Narayanan <[email-masked]> wrote:
> ...
> 
> This offers no additional security and creates a poor user experience. With idempotent tokens, there is no incentive for the attacker to replay than to just use the already generated tokens, which I assume the attacker would have access to given they have access to the code/verifier.

Note that only some OAUTH authorization code grants can be idempotent without being a yncheonous process, as the code is not the only input. For instance, PoP schemes will provide the public or symmetric key portion on the back channel. 

I’m of the mind that multi use SHOULD be a failure, but that does not mean one or both parties SHOULD fail to get an access token. For example, the condition can be found afterward and trigger revocations of the refresh tokens.

-DW
> I would argue that we should also take the opportunity to make Oauth2.1 more meaningful/easier to implement, by reducing unnecessary requirements that offer no additional security.
> 
>> On Sat, Oct 16, 2021 at 10:42 AM Mike Jones <Michael.Jones=[email-masked]> wrote:
>> On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle <richanna=[email-masked]> wrote:
>> 
>> The AS can prevent the authorized client from using one code to get a bunch of independent refresh and access token pairs by either re-issuing the same token (effectively making the token request idempotent) or invalidating previously issued tokens for that code. (Almost but not quite idempotent…idempotent-adjacent?)
>> The AS can prevent unauthorized parties from replaying snooped codes+PKCE by requiring stronger client authentication: implement dynamic client registration and require a replay-resistant client authentication method like `jwt-bearer`. The AS can enforce one-time use of the client credential token without breaking fault tolerance, as the client can easily mint a new one for each retry to the token endpoint.
>>  
>> 
>> On Oct 15, 2021, at 8:27 AM, Mike Jones <Michael.Jones=[email-masked]> wrote:
>> 
>>  
>> 
>> From: OAuth <[email-masked]> On Behalf Of Daniel Fett
>> To: [email-masked]
>> From: OAuth <[email-masked]> On Behalf Of Warren Parad
>> To: Pieter Kasselman <pieter.kasselman=[email-masked]>
>> Cc: IETF oauth WG <[email-masked]>
>> Secure your user data with IAM authorization as a service. Implement Authress.
>> 
>>  
>> 
>>  
>> 
>> On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman <pieter.kasselman=[email-masked]> wrote:
>> 
>> From: OAuth <[email-masked]> On Behalf Of Ash Narayanan
>> To: Aaron Parecki <[email-masked]>
>> Cc: IETF oauth WG <[email-masked]>
>> You don't often get email from [email-masked]. Learn why this is important
>> 
>> On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman <[email-masked]> wrote:
>> 
>> From: OAuth <[email-masked]> On Behalf Of Sascha Preibisch
>> To: Aaron Parecki <[email-masked]>
>> Cc: IETF oauth WG <[email-masked]>
>> On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <[email-masked]> wrote:
>> 
>> Secure your user data with IAM authorization as a service. Implement Authress.
>> 
>>  
>> 
>>  
>> 
>> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <[email-masked]> wrote:
>> 
>> From: OAuth <[email-masked]> On Behalf Of Aaron Parecki
>> To: Warren Parad <wparad=[email-masked]>
>> Cc: Mike Jones <Michael.Jones=[email-masked]>; [email-masked]
>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad <wparad=[email-masked]> wrote:
>> 
>> 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:
>>

---

From: Neil Madden <[email-masked]>
Date: Sat, 16 Oct 2021 07:20:12 +0100

Are we saying that network connections have got significantly worse over the last decade that we need to drop a security feature? I have so far never heard anyone complain about the one-time use nature of authorization codes. (I hear it about refresh tokens, but not auth codes). I don’t think that OAuth 2.1 is an appropriate place to be relaxing any security conditions. 

— Neil

> On 16 Oct 2021, at 03:01, Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> 
> 
> I see the formal reasoning behind the suggestion, and I agree it would be the safest behavior, but I don’t think it’s a realistic expectation. The end user experience necessary for obtaining a new authorization code (with possible future complications if browsers start to see excess redirects toward a domain as evidence of tracking and strip parameters out) and the complexity of moving execution back from code to front channel as error management IMO makes it very unlikely that developers would pursue that approach (which I have never seen implemented in the wild).
> 
>> On Fri, Oct 15, 2021 at 16:42 Mike Jones <Michael.Jones=[email-masked]> wrote:

---

From: Warren Parad <[email-masked]>
Date: Sat, 16 Oct 2021 10:11:45 +0200

I also support Annabelle's suggestion of idempotent tokens. That would
prevent the relaxation and focus on solving the problem scenario, without
opening the door for potential attacks:

> The authorization server MUST generate idempotent tokens from an
> authorization code. Additionally, authorization codes MUST be short lived,
> and if an authorization code is used outside the lifetime or with an
> invalid PKCE verifier, the authorization server MUST deny the request.
>

I'm actually a bit weary of adding the part:

> and SHOULD revoke all tokens previously issued based on authorization
> code.

There are so many times when doing development that someone would have
taken an authorization code and tested it. Causing problems with the user
agent that correctly used the auth code doesn't make sense to me. We
already have a way of denying future tokens, and there is no evidence that
the original token generation was compromised. If it was, then the attacker
should have the access token (and potentially refresh token) which is far
worse.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Sat, Oct 16, 2021 at 8:20 AM Neil Madden <[email-masked]>
wrote:

> Are we saying that network connections have got significantly worse over
> the last decade that we need to drop a security feature? I have so far
> never heard anyone complain about the one-time use nature of authorization
> codes. (I hear it about refresh tokens, but not auth codes). I don’t think
> that OAuth 2.1 is an appropriate place to be relaxing any security
> conditions.
>
> — Neil
>
>>    1. The AS can prevent the authorized client from using one code to
>>    get a bunch of independent refresh and access token pairs by either
>>    re-issuing the same token (effectively making the token request idempotent)
>>    or invalidating previously issued tokens for that code. (Almost but not
>>    quite idempotent…idempotent-adjacent?)
>> *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.
>>
>>
>>
>> I agree with Daniel.
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>> 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
>>
>> 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
>> 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

---

From: Filip Skokan <[email-masked]>
Date: Sat, 16 Oct 2021 12:03:28 +0200

The Slide discussed in the interim proposed dropping multiple measures, not
just the single-use authorization code.

- #65 - single use, discussed in this thread

Normatively defining when and how to allow re-use is a nightmare.

> invalid PKCE verifier, the authorization server MUST deny the request.

This sounds very simple in writing but the same cannot be said about an
implementation. If the same token must be issued from subsequent uses of
the same authorization code, albeit if PKCE verifier is the same this would
imply that the AS needs to store an issued opaque token value referenced
from the authorization code, likewise for a JWT Access Token it must store
its value because of random jtis, or non-deterministic algorithms, that are
at play - otherwise how would "the same" token be issued? One can argue
that its okay to issue a different value token so long as its jti and PoP
cnf, and other claims are the same but that's short-sighted given that
revocation schemes may be based either on jti values or digests of the
token value, the AS cannot know which it is for the client / RS. Then
there's the interplay with DPoP (or future PoP schemes) where it would need
to be the same proof that was passed previously, again having to store it.

Moving from a MUST to a SHOULD with concepts such as "idempotent tokens"
spelled out in security considerations for when the AS decides not to
enforce one-time usage sounds feasible. Leaving it as a MUST, which is, in
light of the above complexity, a way simpler measure is also fine.

But let's not also forget there are two other points on that slide that

- #82 - Should authorization codes be invalidated if used unsuccessfully
- #54 - redirect_uri in token request

It sounds like they should be separated discussions @Aaron Parecki
<[email-masked]>. I'd recommend approaching them separately, not under a
single umbrella. Including these changes in -05 may be premature.

Best,
*Filip Skokan*

On Sat, 16 Oct 2021 at 10:12, Warren Parad <wparad=
[email-masked]> wrote:

>>> 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.
>>>
>>>
>>>
>>> It is also more effort (from a repository layer perspective) to
>>> implement one-time use than do PKCE verification.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>

---

From: Daniel Fett <[email-masked]>
Date: Mon, 18 Oct 2021 08:42:15 +0200

Am 16.10.21 um 03:22 schrieb Ash Narayanan:
> 1. It makes sense (give me the same code/verifier, I'll give you back
> the same tokens).

All I see is that it opens another channel for token exfiltration, for
example if an attacker can read the token request but not the response.
This would be quite a fundamental change.

-Daniel

>     As I see it, the retry in case of network failures should happen
>     by performing a new authorization request – not by trying to reuse
>     an authorization code – which is indistinguishable from an attack.
>
> This offers no additional security and creates a poor user experience.
> With idempotent tokens, there is no incentive for the attacker to
> replay than to just use the already generated tokens, which I assume
> the attacker would have access to given they have access to the
> code/verifier.
>
> I would argue that we should also take the opportunity to make
> Oauth2.1 more meaningful/easier to implement, by reducing unnecessary
> requirements that offer no additional security.
>
>     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.
>
>  
>
>     On Sat, Oct 16, 2021 at 10:42 AM Mike Jones
>     <Michael.Jones=[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     As I see it, the retry in case of network failures should happen
>     by performing a new authorization request – not by trying to reuse
>     an authorization code – which is indistinguishable from an attack.
>
>      
>
>     *From:* Vittorio Bertocci <Vittorio=[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Richard Backman, Annabelle <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Mike Jones <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and
>     OAuth 2.1
>
>      
>
>     I am a fan of this approach. It feels pretty empty to cast people
>     out of compliance just because they are handling a realistic
>     circumstance, such as network failures, that we know about
>     beforehand. 
>
>     In addition, this gives us a chance to provide guidance on how to
>     handle the situation, instead of leaving AS implementers to their
>     own device.
>
>      
>
>     On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle
>     <richanna=[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         This language makes it impossible to build a fault tolerant,
>         spec compliant client, as it prohibits retries. We could
>         discuss whether a retry really constitutes a separate "use",
>         but ultimately it doesn't matter; multiple presentations of
>         the same code look the same to the AS, whether they are the
>         result of retries, the client attempting to get multiple sets
>         I think we can have a fault tolerant, replay-proof
>         implementation, but it takes some effort:
>
>          
>
>          1. The AS can prevent the authorized client from using one
>             code to get a bunch of independent refresh and access
>             token pairs by either re-issuing the same token
>             (effectively making the token request idempotent) or
>             invalidating previously issued tokens for that code.
>             (Almost but not quite idempotent…idempotent-adjacent?)
>          2. The AS can prevent unauthorized parties from replaying
>             snooped codes+PKCE by requiring stronger client
>             authentication: implement dynamic client registration and
>             require a replay-resistant client authentication method
>             like `jwt-bearer`. The AS can enforce one-time use of the
>             client credential token without breaking fault tolerance,
>             as the client can easily mint a new one for each retry to
>             the token endpoint.
>
>          
>
>         Yes, I know, this is way more complex than just a
>         credential-less public client doing PKCE. Perhaps we can have
>         our cake and eat it too with language like:
>
>          
>
>             The client MUST NOT use the authorization code more than
>             once, unless retrying a token request that failed for
>             reasons beyond the scope of this protocol. (e.g., network
>             interruption, server outage) Refer to [Fault Tolerant
>             Replay Prevention] for guidance.
>
>          
>
>         …where Fault Tolerant Replay Prevention is a subsection under
>         Security Considerations. I don't think this wording is quite
>         right, as the guidance is really going to be for the AS, not
>         the client, but hopefully it's enough to get the idea across.
>
>          
>
>         —
>
>         [email-masked] <mailto:[email-masked]>
>
>          
>
>          
>
>
>
>             On Oct 15, 2021, at 8:27 AM, Mike Jones
>             <Michael.Jones=[email-masked]
>             <mailto:Michael.Jones=[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.
>
>              
>
>             I agree with Daniel.
>
>              
>
>             Also, while we’ve talked about server requirements, I
>             think it’s equally important that we retain this client
>             requirement:
>
>              
>
>             *From:* OAuth <[email-masked]
>             <mailto:[email-masked]>> *On Behalf Of *Daniel Fett
>             *To:* [email-masked] <mailto:[email-masked]>
>             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
>
>              
>
>              
>
>              
>
>                 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]>
>                 <mailto:[email-masked]> *On Behalf Of *Warren
>                 Parad
>                 *To:* Pieter
>                 Kasselman <pieter.kasselman=[email-masked]>
>                 <mailto:pieter.kasselman=[email-masked]>
>                 <mailto:[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
>                     *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?
>
>                      
>
>                     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:
>
>                             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
>                             *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:
>
>                                 On Wed, Oct 13, 2021 at 1:50 PM Sascha
>                                 Preibisch <[email-masked]
>                                 <mailto:[email-masked]>> wrote:
>
>                                     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://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:
>
>                                                 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
>
>                                                      
>
>                                                     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]
>                                                     <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"?
>
>                                                          
>
>
>                                                         	
>
>                                                         *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 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
>                                                             <mailto:[email-masked]>
>                                                         <mailto:[email-masked]>
>                                         <mailto:[email-masked]>
>                         [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>
>
>                 https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>              
>
>             -- 
>
>             https://danielfett.de <https://danielfett.de/>
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/oauth>
>
>          
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/oauth>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>

-- 
https://danielfett.de

---

From: Daniel Fett <[email-masked]>
Date: Mon, 18 Oct 2021 08:49:18 +0200

> authorization code – which is indistinguishable from an attack.
It only looks like an attack when the code has actually arrived at the
token endpoint on the first try (which the client cannot know, of course).

I think Annabelle's proposal of allowing reuse-on-error has its merits.
The AS can still reject the code when it has seen the same code already,
and the client can then fall back to starting a new authorization request.

-Daniel

> I am a fan of this approach. It feels pretty empty to cast people out
> of compliance just because they are handling a realistic circumstance,
> such as network failures, that we know about beforehand. 
>
> handle the situation, instead of leaving AS implementers to their own
> device.
>
>  
>
>     compliant client, as it prohibits retries. We could discuss
>     whether a retry really constitutes a separate "use", but
>     ultimately it doesn't matter; multiple presentations of the same
>     code look the same to the AS, whether they are the result of
>     retries, the client attempting to get multiple sets of tokens, or
>     an unauthorized party trying to replay the code.
>
>      
>
>      1. The AS can prevent the authorized client from using one code
>         to get a bunch of independent refresh and access token pairs
>         by either re-issuing the same token (effectively making the
>         token request idempotent) or invalidating previously issued
>         tokens for that code. (Almost but not quite
>         codes+PKCE by requiring stronger client authentication:
>         implement dynamic client registration and require a
>         replay-resistant client authentication method like
>         `jwt-bearer`. The AS can enforce one-time use of the client
>         credential token without breaking fault tolerance, as the
>         client can easily mint a new one for each retry to the token
>         endpoint.
>
>      
>
>     Yes, I know, this is way more complex than just a credential-less
>     public client doing PKCE. Perhaps we can have our cake and eat it
>     too with language like:
>
>      
>
>         The client MUST NOT use the authorization code more than once,
>         unless retrying a token request that failed for reasons beyond
>         the scope of this protocol. (e.g., network interruption,
>         server outage) Refer to [Fault Tolerant Replay Prevention] for
>         guidance.
>
>      
>
>     right, as the guidance is really going to be for the AS, not the
>     client, but hopefully it's enough to get the idea across.
>
>      
>
>     —
>

-- 
https://danielfett.de