> On 11. May 2020, at 10:59, Neil Madden wrote:
>
>
>
>> On 11 May 2020, at 08:53, Torsten Lodderstedt
>> wrote:
>>
>>
>>
>>> On 11. May 2020, at 09:34, Neil Madden wrote:
>>>
>>>
>>>
On 11 May 2020, at 08:05, Torsten Lodderstedt
wrote:
>> On 11.
> On 11 May 2020, at 08:53, Torsten Lodderstedt wrote:
>
>
>
>> On 11. May 2020, at 09:34, Neil Madden wrote:
>>
>>
>>
>>> On 11 May 2020, at 08:05, Torsten Lodderstedt
>>> wrote:
>>>
>>>
>>>
> On 11. May 2020, at 08:47, Neil Madden wrote:
>
>
>
>> On 11 May
> On 11. May 2020, at 09:34, Neil Madden wrote:
>
>
>
>> On 11 May 2020, at 08:05, Torsten Lodderstedt
>> wrote:
>>
>>
>>
On 11. May 2020, at 08:47, Neil Madden wrote:
> On 11 May 2020, at 07:41, Torsten Lodderstedt
> wrote:
> On 11. May
> On 11 May 2020, at 08:05, Torsten Lodderstedt wrote:
>
>
>
>>> On 11. May 2020, at 08:47, Neil Madden wrote:
>>>
>>>
>>>
On 11 May 2020, at 07:41, Torsten Lodderstedt
wrote:
>>>
On 11. May 2020, at 07:38, Neil Madden wrote:
There is no attack that this
> On 11. May 2020, at 08:47, Neil Madden wrote:
>
>
>
>> On 11 May 2020, at 07:41, Torsten Lodderstedt
>> wrote:
>>
>>> On 11. May 2020, at 07:38, Neil Madden wrote:
>>>
>>> There is no attack that this prevents so your claim of improving security
>>> is unsubstantiated. I can’t see
> On 11 May 2020, at 07:41, Torsten Lodderstedt wrote:
>
>> On 11. May 2020, at 07:38, Neil Madden wrote:
>>
>> There is no attack that this prevents so your claim of improving security is
>> unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default AS
>> while this
> On 11. May 2020, at 07:38, Neil Madden wrote:
>
> There is no attack that this prevents so your claim of improving security is
> unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default AS
> while this requirement remains so I don’t support it.
Are you saying PKCE does not
There is no attack that this prevents so your claim of improving security is
unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default AS
while this requirement remains so I don’t support it.
Neil
> On 11 May 2020, at 01:35, Dick Hardt wrote:
>
>
> It is a MUST to enforce
It is a MUST to enforce consistency across all clients, and therefore to
improve security for all clients.
An AS can decide to be OAuth 2.1 for all new clients, and encourage
existing clients to migrate to OAuth 2.1 (add support for PKCE).
If the client wants OAuth 2.1, the AS will enforce it.
Let’s go back to basics. Why is this clause a MUST in the 2.1 spec? What does
that accomplish?
It doesn’t provide any security benefit - an attacker can just as easily send a
code_challenge as a legitimate client, there’s no secret involved. So enforcing
PKCE in this way doesn’t prevent any
Sounds like your clients that have set PKCE to be mandatory will then be
OAuth 2.1 compliant with no extra work.
A deployment can decide when they want to be compliant. That is not the
specifications decision. I'm unclear on what point you are wanting to make
below.
On Sun, May 10, 2020 at 1:28
This is the same as having 2.1 compliance turned off by default. We already
have a per-client setting to make PKCE mandatory.
If you can turn it off, what’s the point of making it a MUST in the spec? What
does an optional MUST even mean for an AS to claim 2.1 compliance?
> On 10 May 2020, at
Is there a reason why a server can not support both OAuth 2.0 and OAuth
2.1? The version supported could be dependent on the client id, ie older
clients could still be OAuth 2.0, and newer clients would be OAuth 2.1, and
PKCE would be enforced.
ᐧ
On Sun, May 10, 2020 at 1:05 PM Neil Madden
But if an AS upgrades to OAuth 2.1 then it MUST reject authorization requests
that don’t include a code_challenge (section 4.1.2.1), so this will only be
possible when all clients support PKCE.
This makes it impossible for a 2.1-compliant AS to also support non-PKCE 2.0
clients (i.e., the vast
Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as
the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth
2.0 was voluntary.
Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?
On Sun, May 10, 2020 at 12:02 PM Mike Jones wrote:
I agree with actively maintaining and improving the OAuth 2.0 specs by adding
enhancements that are voluntary to use. I’ve worked on many such improvements,
including Dynamic Client Registration, Authorization Metadata, the Device Flow,
Token Exchange, DPoP, and support PAR and RAR, etc. The
Yes, the BCP says *clients* may use either PKCE or nonce to prevent
authorization code injection. Shortly after that quoted segment is the
below:
> Authorization servers MUST support PKCE [RFC7636].
On Wed, May 6, 2020 at 12:22 PM Mike Jones
wrote:
> Aaron, the section you cited at
>
Aaron, the section you cited at
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1
makes it clear that clients can support EITHER PKCE or the OpenID Connect
nonce. The text is:
Clients MUST prevent injection (replay) of authorization codes into
the
18 matches
Mail list logo
