> 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 requiremen
> 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 clie
> 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 con
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 that
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.
I
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 dir
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
We are NOT saying that an OAuth 2.0 compatible server is OAuth 2.1
compatible. For example, an OAuth 2.0 compatible server does not have to
support PKCE, support the implicit grant, support the Resource Owner
Password Credentials grant, support bearer tokens in the query string of
the URI, etc.
htt
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 21
The difference is that OAuth 2.1 is supposed to compatible with OAuth 2.0
(which is my whole goal here), whereas 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
Exactly!
I believe that this also the same point that Brian Campbell was making earlier
about interoperability implications.
-- Mike
From: Neil Madden
Sent: Sunday, May 10, 2020 1:06 PM
To: Dick Hardt
Cc: Mike Jones ; oauth@ietf.org; Tors
As a clarifying question, you are saying "Servers must support" and not
"Servers must require clients to use PKCE".
-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152
On Wed, May 6, 2020 at 4:04 PM Mike Jones wrote:
> As is being discussed in the thread “[OAUTH-WG] OA
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
wrote:
Not exactly the same, but seems similar to some of the proposed logic in
https://tools.ietf.org/wg/oauth/draft-ietf-oauth-incremental-authz/
-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152
On Tue, May 5, 2020 at 10:19 AM Jim Schaad wrote:
> Over in the ACE working
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
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 practices.
If existing deployments don'
If I’m not mistaken, the OAuth 2.1 draft is intended to make OAuth 2.0 (RFC
6749) obsolete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC 5849)
obsolete. That’s what makes me think developers would view updating as
mandatory. If you’re willing to remove the “replaces 6749” clause from the
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:
>
> 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
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 i
Hi Beena,
This sounds like a great use of the client credentials grant. The password
grant is being removed from OAuth 2.0 by the Security Best Current
Practice. Can you clarify what you've found useful about the password grant
that the client credentials grant doesn't solve?
Aaron Parecki
On S
I just read over the diff between -21 and -22 and realised the example in
Section 5.2.2.
https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
%2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS13
Hi,
We have a product with client server architecture where our server manages
thousands of devices. Each device has a client-piece that talks to the
server over SOAP/REST. The client currently uses a HTTP Basic
Authentication (unique id and a secret string) for all the calls. The
secret string i
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 unneces
Hi Mike,
Mike Jones 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 that decision. Can you please refer to the
respective thread?
Requiring exact redirect URI matching is already a breaking change. Do you
oppose aga
26 matches
Mail list logo
