There is no specific mechanism right now. But future developers won’t be able to read the reason why the extension point is given only for confidential clients.
> On May 14, 2020, at 18:32, Torsten Lodderstedt <[email protected]> > wrote: > > Are you aware of any suitable mechanism? I’m asking since from my perspective > this clause is mainly intended to allow existing OpenID Connect deployments > to use nonce instead of PKCE in combination with OAuth 2.1. It’s a > compromise. I think we should not encourage others to invent their own OAuth > security mechanisms. > >> On 14. May 2020, at 09:37, Nov Matake <[email protected]> wrote: >> >> Hi, >> >> Why not allowing public clients use "other suitable mechanisms” then? >> OAuth WG can allow both type of clients do so, then OIDF will define nonce >> as the alternative only for confidential clients. >> >>> 2020/05/14 15:56、Torsten Lodderstedt >>> <[email protected]>のメール: >>> >>> Hi all, >>> >>> I would also like to thank everybody for the substantial discussion. >>> >>> The proposed change for Section 4.1.2.1 works for me (as already stated). >>> I’m not fully comfortable with the proposed change for Section 9.7 for the >>> following reasons: >>> >>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE >>> instead of requiring it (with a well-defined exception). >>> - Given the latest findings re nonce I don’t feel comfortable with >>> recommending any mechanism that this WG is not responsible for and thus did >>> not conduct the security threat analysis for. I think the better way for us >>> as WG is to define the extension point for other mechanisms. The OpenID >>> Foundation (or any other body) can then fill in and issue a statement that >>> nonce (or another suitable mechanism) fulfils the requirements of the >>> extension point. >>> >>> Based on this considerations, I propose the following text for Section 9.7: >>> >>> Clients MUST prevent injection (replay) of authorization codes into >>> the authorization response by attackers. Public clients MUST use the >>> "code_challenge” with a transaction-specific value that is >>> securely bound to the client and the user agent in which the >>> transaction was started. Confidential clients MUST use >>> the “code_challenge” in the same way or other suitable mechanisms to >>> mitigate authorization code injection. >>> >>> This text follows the logic in Section 4.1.2.1 and allows use of the nonce >>> for confidential clients. >>> >>> best regards, >>> Torsten. >>> >>>> On 12. May 2020, at 02:21, Mike Jones >>>> <[email protected]> wrote: >>>> >>>> That works for me. Thanks all for the useful back-and-forth that got us >>>> to this point of clarity. I suspect many of us learned things along the >>>> way; I know that I did! >>>> >>>> Cheers, >>>> -- Mike >>>> >>>> From: Aaron Parecki <[email protected]> >>>> Sent: Monday, May 11, 2020 4:55 PM >>>> To: OAuth WG <[email protected]> >>>> Cc: Neil Madden <[email protected]>; Mike Jones >>>> <[email protected]> >>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1 >>>> >>>> Thank you Neil. >>>> >>>> To address Mike's concerns in the previous threads, I would like to also >>>> update section 9.7 with the following text: >>>> >>>> Clients MUST prevent injection (replay) of authorization codes into the >>>> authorization response by attackers. The use of the `code_challenge` >>>> parameter is RECOMMENDED to this end. For confidential clients, the >>>> OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be used >>>> instead of or in addition to the `code_challenge` parameter for this >>>> purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be >>>> transaction-specific and securely bound to the client and the user agent >>>> in which the transaction was started. >>>> >>>> This change better clarifies the specific circumstances under which the >>>> "nonce" parameter is sufficient to protect against authorization code >>>> injection. >>>> >>>> Aaron Parecki >>>> >>>> On Mon, May 11, 2020 at 11:55 AM Neil Madden <[email protected]> >>>> wrote: >>>> I am happy with this proposed wording. Thanks for updating it. >>>> >>>> — Neil >>>> >>>> >>>> On 11 May 2020, at 19:52, Aaron Parecki <[email protected]> wrote: >>>> >>>> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone! >>>> >>>> We would like to propose the following text, which is a slight variation >>>> from the text Neil proposed. This would replace the paragraph in 4.1.2.1 >>>> (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) >>>> that begins with "If the client does not send the "code_challenge" in the >>>> request..." >>>> >>>> "An AS MUST reject requests without a code_challenge from public clients, >>>> and MUST reject such requests from other clients unless there is >>>> reasonable assurance that the client mitigates authorization code >>>> injection in other ways. See section 9.7 for details." >>>> >>>> Section 9.7 is where the nuances of PKCE vs nonce are described. >>>> >>>> As Neil described, we believe this will allow ASs to support both OAuth >>>> 2.0 and 2.1 clients simultaneously. The change from Neil's text is the >>>> clarification of which threats, and changing to MUST instead of SHOULD. >>>> The "MUST...unless" is more specific than "SHOULD", and since we are >>>> already describing the explicit exception to the rule, it's more clear as >>>> a MUST here. >>>> >>>> Aaron Parecki >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
