eusing 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
pers 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.
>>>
>>&g
in.
>>
>>
>>
>> -- Mike
>>
>>
>>
>> *From:* Vittorio Bertocci
>> *Sent:* Friday, October 15, 2021 4:19 PM
>> *To:* Richard Backman, Annabelle
>> *Cc:* Mike Jones ; oauth
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 and OAuth 2.1
>>
>>
>>
>> I am a fan of this ap
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]
] 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
t; 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 code
Authorization Code and the Code Verifier
from a log and replay it.
Cheers
Pieter
From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf
Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad
mailto:40rhosys...@dmarc.ietf.org>>
Cc: Mike Jones
mailto:40microso
boun...@ietf.org>> 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 r
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, a
(It's a bit of a tangent, but having the PKCE for confidential clients
severely cuts down on extra complexity for client platforms/development
teams when an AS choses to allow it for some clients and not for others.
Consistency here is a good thing, since it's fairly easy to implement the
roundtrip
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 use
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 as
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 tha
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
revok
19 matches
Mail list logo
