g an authorization code needs to remain.
>
>
>
> -- Mike
>
>
>
> *From:* Vittorio Bertocci
> *Sent:* Friday, October 15, 2021 4:19 PM
> *To:* Richard Backman, Annabelle
> *Cc:* Mike Jones ; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse a
>
>>> …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.
t;>
>>
>> -- Mike
>>
>>
>>
>> *From:* Vittorio Bertocci
>> *Sent:* Friday, October 15, 2021 4:19 PM
>> *To:* Richard Backman, Annabelle
>> *Cc:* Mike Jones ; oauth@ietf.
—
>>
>> Annabelle Backman (she/her)
>>
>> richa...@amazon.com
>>
>>
>>
>>
>>
>>
>>
>>
>> On Oct 15, 2021, at 8:27 AM, Mike Jones
>> wrote:
>>
>>
>>
>> CAUTION: This email ori
ehaviors that we
>> can’t distinguish from attacks.
>>
>>
>>
>> The prohibition on clients reusing an authorization code needs to remain.
>>
>>
>>
>> -- Mike
>>
>>
>>
>> From: Vittorio Bertocci
>> Sent
> *Sent:* Friday, October 15, 2021 4:19 PM
> *To:* Richard Backman, Annabelle
> *Cc:* Mike Jones ; oauth@ietf.org
> *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
gt; -- Mike
>
>
>
> *From:* Vittorio Bertocci
> *Sent:* Friday, October 15, 2021 4:19 PM
> *To:* Richard Backman, Annabelle
> *Cc:* Mike Jones ; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization
] 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
;
>
> 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 *On
> Behalf Of *Warren Parad
&
On Behalf Of Daniel Fett
Sent: Friday, October 15, 2021 8:13 AM
To: oauth@ietf.org
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
> On Behalf
Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad
mailto:40rhosys...@dmarc.ietf.org>>
Cc: Mike Jones
mailto:40microsoft....@dmarc.ietf.org>>;
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAu
I agree that PKCE (with a non-plain operational mode) protects the code from
attacker use by the security BCP model (but not necessarily stronger models)
Would the prevalence for ASs which cannot enforce an atomic code grant warrant
further language against plain PKCE?
-DW
> On Oct 13, 2021,
(It's a bit of a tangent, but having the PKCE for confidential clients
severely cuts down on extra complexity for client platforms/development
teams when an AS choses to allow it for some clients and not for others.
Consistency here is a good thing, since it's fairly easy to implement the
PKCE is built in to the authorization code flow in OAuth 2.1 and does not
depend on the client type.
Neil does bring up a good point about the "plain" challenge type though.
The "plain" type does undermine some of the security guarantees that PKCE
provides. The Security BCP does recommend against
Thanks Aaron, that's a great point. In light of that, I would ask about the
recommendation for non-SPA. I was under the impression that non-SPA's don't
require the use of PKCE, which would make them vulnerable to replay
attacks. Or am I missing something?
Warren Parad
Founder, CTO
Secure your
I wasn’t on the call either, so maybe I’m missing something. If you’re using
PKCE with the “plain” challenge type then both the auth code and the verifier
are exposed in redirect URI parameters in the user-agent aren’t they? That
seems a bit risky to drop the one-time use requirement.
I can’t
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
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
18 matches
Mail list logo
