.
-- Mike
*From:* Torsten Lodderstedt
*Sent:* Sunday, May 10, 2020 3:15 AM
*To:* Mike Jones
*Cc:* Daniel Fett ; oauth@ietf.org
*Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
Hi Mike,
Mike Jones schrieb am Fr. 8.
Mai 2020 um 18:55:
OAuth 2.1 was supposed
> On 10. May 2020, at 21:02, Mike Jones wrote:
>
> > Did I got it right that nonce does not protect public clients from code
> > theft/replay?
>
> I believe that the OpenID Connect Code Hash (“c_hash”) claim protects against
> this.
c_hash is designed to prevent injection at a legit
My apologies for a tangent on an already-long thread...
On Fri, May 08, 2020 at 08:50:16AM +0200, Daniel Fett wrote:
>
> Yes, this will make a number of implementations non-spec-compliant, but
> I do not think that this is a huge problem. Software needs to adapt all
> the time and a software
OAuth 2.0 was incompatible with
> OAuth 1.0 by design.
>
>
>
> *From:* Dick Hardt
> *Sent:* Sunday, May 10, 2020 12:58 PM
> *To:* Mike Jones
> *Cc:* Torsten Lodderstedt ; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
>
: [OAUTH-WG] OAuth 2.1 - require PKCE?
Just as upgrading to OAuth 2.0 from OAuth 1.0 was voluntary, why is upgrading
to OAuth 2.1 not voluntary?
OAuth 2.0 obsoleted OAuth 1.0, just as OAuth 2.1 is obsoleting OAuth 2.1. Our
goal is for new deployments, that are reading the drafts, to use the best
t.com>>
Cc: Daniel Fett mailto:f...@danielfett.de>>;
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
Hi Mike,
Mike Jones
mailto:40microsoft@dmarc.ietf.org>>
schrieb am Fr. 8. Mai 2020 um 18:55:
OAuth 2.1 was supposed t
gt; *To:* Mike Jones
> *Cc:* Torsten Lodderstedt ; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> 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
th@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
Hi Mike,
Mike Jones
mailto:40microsoft@dmarc.ietf.org>>
schrieb am Fr. 8. Mai 2020 um 18:55:
OAuth 2.1 was supposed to not introduce breaking changes.
I cannot remember the WG met
> Did I got it right that nonce does not protect public clients from code
> theft/replay?
I believe that the OpenID Connect Code Hash (“c_hash”) claim protects against
this. I’d be interested in hearing John Bradley’s take on this.
--
Mike Jones schrieb am Sa. 9. Mai 2020 um
20:46:
> There’s a huge ecosystem of successful, secure OAuth 2.0 and OpenID
> Connect deployments that we have the responsibility to be stewards of.
> This working group should be proud of what it’s accomplished. Part of good
> stewardship is not
.
> Kind regards,
Torsten.
>
>-- Mike
>
>
>
> *From:* OAuth *On Behalf Of * Daniel Fett
> *Sent:* Thursday, May 7, 2020 11:50 PM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
&g
There’s a huge ecosystem of successful, secure OAuth 2.0 and OpenID Connect
deployments that we have the responsibility to be stewards of. This working
group should be proud of what it’s accomplished. Part of good stewardship is
not unnecessarily bifurcating the ecosystem into
>
> Aaron, I believe you’re trying to optimize the wrong thing. You’re
> concerned about “the amount of explanation this will take”. That’s
> optimizing for spec simplicity – a goal that I do understand. However, by
> writing these few sentences or paragraphs, we’ll make it clear to
>
of approval by the OAuth working group.
-- Mike
From: Phillip Hunt
Sent: Friday, May 8, 2020 12:45 PM
To: Dick Hardt
Cc: Philippe De Ryck ; Mike Jones
; OAuth WG
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
We are not discussing
On Fri, May 8, 2020 at 12:42 PM Aaron Parecki wrote:
> > FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is
> OAuth 2.0 with best practices.
>
> The line there is kind of fuzzy. The objective is not to introduce new
> concepts, however there are some changes defined that
We are not discussing anything new here. We are discussing adoption of best
practice.
The disconnect appears to be that one dependent standard’s “typical” use
(nonces) does not have the ietf consensus as best practice.
This lack of consensus needs to be resolved.
Phil
> On May 8, 2020, at
> FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is
OAuth 2.0 with best practices.
The line there is kind of fuzzy. The objective is not to introduce new
concepts, however there are some changes defined that are "breaking
changes" from plain OAuth 2.0, because those things
FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is
OAuth 2.0 with best practices.
On Thu, May 7, 2020 at 10:36 PM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:
> From working with a lot of developers on understanding OAuth 2.0 and OIDC,
> I definitely vote
hursday, May 7, 2020 11:50 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
+1 to all what Aaron said. Thanks for pointing this out!
We need to address this in the security BCP and this will be a normative change
that affects OpenID Connect Core (just as our current re
+1
Phil
> On May 7, 2020, at 11:50 PM, Daniel Fett wrote:
>
>
> +1 to all what Aaron said. Thanks for pointing this out!
>
> We need to address this in the security BCP and this will be a normative
> change that affects OpenID Connect Core (just as our current recommendation
> on the
+1 to all what Aaron said. Thanks for pointing this out!
We need to address this in the security BCP and this will be a normative
change that affects OpenID Connect Core (just as our current
recommendation on the usage of nonce).
We would then have:
- use PKCE, except if you use OIDC with a
From working with a lot of developers on understanding OAuth 2.0 and OIDC, I
definitely vote for simplicity. Understanding the subtle nuances of when a
nonce is fine and when PKCE should be used is impossible without in-depth
knowledge of the flows and their properties. Misunderstandings will
Aaron, I believe you’re trying to optimize the wrong thing. You’re concerned
about “the amount of explanation this will take”. That’s optimizing for spec
simplicity – a goal that I do understand. However, by writing these few
sentences or paragraphs, we’ll make it clear to developers that
Backing up a step or two, there's another point here that I think has been
missed in these discussions.
PKCE solves two problems: stolen authorization codes for public clients,
and authorization code injection for all clients. We've only been talking
about authorization code injection on the list
Mike
>>
>>
>>
>> *From:* Aaron Parecki
>> *Sent:* Wednesday, May 6, 2020 12:24 PM
>> *To:* Mike Jones
>> *Cc:* Dick Hardt ; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> Yes, the BCP says *cli
for the change to the Security BCP to make it self-consistent.
-- Mike
From: Aaron Parecki
Sent: Wednesday, May 6, 2020 1:43 PM
To: Mike Jones
Cc: Dick Hardt ; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
Going back
cki
>> *Sent:* Wednesday, May 6, 2020 12:24 PM
>> *To:* Mike Jones
>> *Cc:* Dick Hardt ; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> Yes, the BCP says *clients* may use either PKCE or nonce to prevent
>> authorizat
t; *From:* Aaron Parecki
> *Sent:* Wednesday, May 6, 2020 12:24 PM
> *To:* Mike Jones
> *Cc:* Dick Hardt ; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Yes, the BCP says *clients* may use either PKCE or nonce to prevent
> authorization code
.
-- Mike
From: Phillip Hunt
Sent: Wednesday, May 6, 2020 1:16 PM
To: Mike Jones
Cc: Aaron Parecki ; Steinar Noem ;
oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
Why couldn’t OIDC evolve as a spec to conform and match FAPI and 2.1?
Phil
On May 6, 2020, at 12:34
-- Mike
>
> From: Aaron Parecki
> Sent: Wednesday, May 6, 2020 12:29 PM
> To: Steinar Noem
> Cc: Phillip Hunt ; Mike Jones
> ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
> I should add that even some OpenID Connect profiles require PKCE,
as stewards of the OAuth ecosystem.
-- Mike
From: Aaron Parecki
Sent: Wednesday, May 6, 2020 12:29 PM
To: Steinar Noem
Cc: Phillip Hunt ; Mike Jones
; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
I should add that even some
Jones
Cc: Dick Hardt ; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
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
to retroactively impose
>>>> unnecessary requirements on existing deployments is unlikely to succeed and
>>>> will significantly reduce the relevance of the OAuth 2.1 effort.
>>>>
>>>>
>>>>
>>>> In particular, authorization servers shouldn’t be required to support
>>&
eady support the OpenID Connect nonce. And clients
>>> shouldn’t reject responses from servers that don’t support PKCE when they
>>> do contain the OpenID Connect nonce. Doing so would unnecessarily break
>>> things and create confusion in the marketplace.
>>>
&g
t; In particular, authorization servers shouldn’t be required to support PKCE
>>>> when they already support the OpenID Connect nonce. And clients shouldn’t
>>>> reject responses from servers that don’t support PKCE when they do contain
>>>> the OpenID
necessarily break
>> things and create confusion in the marketplace.
>>
>>
>>
>> -- Mike
>>
>>
>>
>> *From:* OAuth *On Behalf Of * Dick Hardt
>> *Sent:* Wednesday, May 6, 2020 10:48 AM
t;> reject responses from servers that don’t support PKCE when they do contain
>> the OpenID Connect nonce. Doing so would unnecessarily break things and
>> create confusion in the marketplace.
>>
>>
>>
>> -- Mike
>>
>>
>>
ntain
> the OpenID Connect nonce. Doing so would unnecessarily break things and
> create confusion in the marketplace.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth *On Behalf Of * Dick Hardt
> *Sent:* Wednesd
On Behalf Of Dick Hardt
Sent: Wednesday, May 6, 2020 10:48 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?
Hello!
We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best
practice for OAuth 2.0. It is not common in OpenID Connect servers as the nonce
solves
Hello!
We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best
practice for OAuth 2.0. It is not common in OpenID Connect servers as the
nonce solves some of the issues that PKCE protects against. We think that
most OpenID Connect implementations also support OAuth 2.0, and
40 matches
Mail list logo
