Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

Francis Pouatcha <fpo@adorsys.de> Tue, 12 May 2020 17:23 UTC

Return-Path: <fpo@adorsys.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EC13A07E7 for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 10:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1GYSmyenP-v for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 10:23:25 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD533A0780 for <oauth@ietf.org>; Tue, 12 May 2020 10:23:24 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id l17so2977631wrr.4 for <oauth@ietf.org>; Tue, 12 May 2020 10:23:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TK31YwjXIEquJJsuMBg/SPqgiV0tqn57MieoUPXIta0=; b=SUmJUlNfPU1/E5o2SRqqreXCI3X9U6fKOJcmkHNHVH90Tc5A5FJmWQWcpsmaKWDoRr Pvj4XDHzTQe3BPk+sVyZN9V65AbiSiwzUHCs4sVA0QKnDdUz1lirsXzhmvHW5NjSLT5N 2YQP+/JTYrETO2Yr3PnhDXjd9qyZlw5ra1F4g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TK31YwjXIEquJJsuMBg/SPqgiV0tqn57MieoUPXIta0=; b=sERDrnWbH8cHINVYNFhEvB5ldDPRWwqArbYkginTLF2vNIFQcCVrhsUrlfV1G0/iTp d3N8911lsvD4lByNpNMsr3KgmJMph0q9Trm8vLiRupNGfWjcqz8Ij6TXH1k8bHHsscr/ SZDaCTE2NnRDSuQo9UmPZRVQVJR9Lt+47cPGkRRwH7CUt771hwTW0ukIFcClFA9ok3EU O2Fqp9SMKDq7mWCQ0Qwwy2vGxP+rZc/Uj+aqdU+eHP/bsNwv9z3Gep1MZfHlkl91UhgW 47g6Zou+Uy3xHSIACTFgS90agi7Mu8Ve3TZcw5b5I/sXCcfhnMdl4iJIRhXh+0q9MmWe Z6hA==
X-Gm-Message-State: AGi0PubG1unMbizDry2taNc0kehcDHZEdGyhMjchdOKdNEVB4C+CAVnv nQT9alLDBjVXG2Qyn5th/jC9LEVU9REqFWUIct8IBjn/DO0BPA==
X-Google-Smtp-Source: APiQypLMcjucS8jja3bAC5o4x+8v76VUO2L8oC3JVquUu++Fvk2iAUQQieKmpYSCR3h7R2zp+roSNN5FVYNmBOpViW4=
X-Received: by 2002:adf:8169:: with SMTP id 96mr25907331wrm.283.1589304202591; Tue, 12 May 2020 10:23:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyNY768vqFtxxHXNd2u+VXFoiW=+BG+AJNW0Ee9H13V3zQ@mail.gmail.com> <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com>
In-Reply-To: <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Tue, 12 May 2020 13:23:11 -0400
Message-ID: <CAOW4vyM3Vi4eHCCn1x5-0K0S8pP5qtpTByNYS4DP8EaSqiWn5Q@mail.gmail.com>
To: Jim Manico <jim@manicode.com>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006f9ce105a576b890"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/WfttjzzNRHvwCnqZqIeVaYSlPXc>
Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2020 17:23:27 -0000

On Tue, May 12, 2020 at 9:50 AM Jim Manico <jim@manicode.com> wrote:

> Forgive me if this question is late or poor context, but wouldn’t OIDC be
> a better replacement for ROPC since it’s essentially a authentication flow?
>
> What use case for ROPC mandates OAuth2 over OIDC?
>
We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1
forbidding the user of ROPC.


> --
> Jim Manico
> @Manicode
>
> On May 11, 2020, at 11:00 PM, Francis Pouatcha <fpo=
> 40adorsys.de@dmarc.ietf.org> wrote:
>
> 
> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password
> Credentials) with the following reasoning:
>
> Auth Code Grant:
> There are  many use cases on the market where redirection based flows do
> not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the
> complexity of user agents on non controllable client devices still make
> user agent redirection a challenge.
>
> Client Credentials Grant:
> Requires the registration of an oAuth client.
> - Citing the iot device use cases Beena which do not have a comfortable
> way to have iot devices register with AS.
> - This is a registration flow for the oAuth client role  and for the RO
> (Resource Owner). Remember resource owner credentials might be sourced from
> system external to the AS  like company's LDAP. oAuth Client Credentials
> are generally managed by the AS.
> For these reasons, we shall not use Client Credential Grant to manage RO
> authorization.
>
> ROPC:
> Having an oAuth Client proxy the auth request of the RO to the AS only
> presents a security risk if the oAuth Client is a third party application.
> Therefore, the decision on whether to accept ROPC for a specified client
> shall be left to the AS. Discarding this use case will take a lot of
> business from oAuth servers back to the old market.
>
> Beside this, I mentioned in my previous post that there are use cases in
> the market where permanent passwords are replaced with one time passwords.
>
> A lot of work is also being done in the direction of having the RO send
> signed proof of ownership to the AS through the ROPC  flow using the
> password field.
>
> Therefore, I am ok with raising the attention of  implementers the same
> way we are doing with PKCE,  mentioning that ROPC  must only be used if  AS
> / oAuth Client can guarantee security of the RO credentials exposed to the
> oAuth Client.
>
> /Francis
> --
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/