The document is called "...Best Current Practice ..." and includes
recommendations. Could it be sufficient to say "Authorization servers
support PKCE" in section 2.1.1? I believe MUST and other such terms
may not necessarily belong into such document.
Regards,
Sascha
On Wed, 6 May 2020 at
I think the point is that the Security BCP in
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1..1
requires that the authz request has either the PKCE "code_challenge" or the
OIDC "nonce". Whereas 2.1 in
As is being discussed in the thread "[OAUTH-WG] OAuth 2.1 - require PKCE?",
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1
has inconsistent requirements for PKCE support between clients and servers.
Per the first paragraph, clients must either use PKCE or use the
Requiring a change to every deployed RP is not “a very small leap”. It’s an
invasive big deal, introducing a breaking change and bifurcating a
well-functioning ecosystem without sufficient cause.
What this actually points out to me is that we should modify the language in
the Security BCP to
I hear Mike's point on breaking existing RPs. There are alot of them out
there.
For discussion purposes, let's call the current version OIDC 1.0 and the
version running OAuth 2.1, OIDC 1.1
Is there a reason a server can't be running both versions at the same time,
and support clients running
Going back to this point about server vs client requirements, since both
the Security BCP and OAuth 2.1 currently say that ASs MUST support PKCE,
isn't that already imposing additional requirements on OpenID Connect
providers that don't currently exist in OpenID Connect alone?
OPs that want to be
It could, but that would require an explicit decision by the OpenID Connect
working group to make existing RPs incompatible with new OPs, breaking
interoperability. That’s not a decision we should make lightly or without a
compelling reason to do so.
Why couldn’t OIDC evolve as a spec to conform and match FAPI and 2.1?
Phil
> On May 6, 2020, at 12:34 PM, Mike Jones wrote:
>
>
> Yes, FAPI requires PKCE, which is great. Many of its requirements come from
> OpenID Connect but some of them are intentionally incompatible – such as
>
Yes, FAPI requires PKCE, which is great. Many of its requirements come from
OpenID Connect but some of them are intentionally incompatible – such as
requiring that Basic authentication not be supported, whereas Connect requires
that it be supported. It’s a different ecosystem with different
I realize what it says about servers. My point is that OAuth 2.1’s
requirements on clients should match those in the security BCP and not try to
go beyond them.
-- Mike
From: Aaron Parecki
Sent: Wednesday, May 6, 2020 12:24 PM
To: Mike
I should add that even some OpenID Connect profiles require PKCE, such as
FAPI:
https://openid.net/specs/openid-financial-api-part-1.html#authorization-server
So the precedent for requiring PKCE already exists within some OpenID
Connect profiles.
On Wed, May 6, 2020 at 12:23 PM Aaron Parecki
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
>
Yes, and also, many of those providers very likely already support PKCE
already. Skimming through that list of certified OPs, I recognize many
names there from providers that I know support PKCE.
On Wed, May 6, 2020 at 12:18 PM Steinar Noem wrote:
> So, wouldn't a MUST just mean that we would
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
Yes. Some would be 2.0 and some2.1. Not unlike TLS versioning.
Maybe i should not have said that. ;-)
Phil
> On May 6, 2020, at 12:18 PM, Steinar Noem wrote:
>
>
> So, wouldn't a MUST just mean that we would have some OPs that are 2.1
> compliant and some that aren't?
>
>> ons. 6. mai
So, wouldn't a MUST just mean that we would have some OPs that are 2.1
compliant and some that aren't?
ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt :
> Mike,
>
> The point of 2.1 is to raise the security bar.
>
> Yes it adds new MUST requirements.
>
> But what about OIDC would break other than
Mike,
The point of 2.1 is to raise the security bar.
Yes it adds new MUST requirements.
But what about OIDC would break other than required implementation of PKCE to
support 2.1?
Eg Would additional signaling be required to facilitate interoperability and
migration between versions? Would
> In particular, authorization servers shouldn’t be required to support
PKCE when they already support the OpenID Connect nonce.
The Security BCP already requires that ASs support PKCE:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1..1
Are
you suggesting that the
The disadvantage of requiring PKCE for OpenID Connect implementations is that
you’re trying to add a normative requirement that’s not required of OpenID
Connect deployments today, which would bifurcate the ecosystem. There are
hundreds of implementations (including the 141 certified ones at
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
20 matches
Mail list logo
