Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
Falk Andreas <Andreas.Falk@novatec-gmbh.de> Tue, 12 May 2020 19:50 UTC
Return-Path: <prvs=1401dc60c2=andreas.falk@novatec-gmbh.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 BFB403A0A3B
for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 12:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 9JUgh5WTdg9l for <oauth@ietfa.amsl.com>;
Tue, 12 May 2020 12:50:33 -0700 (PDT)
Received: from ce-mxgw-01.corbox-factory.de (ce-mxgw-01.corbox-factory.de
[185.55.154.21])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 0393D3A0A27
for <oauth@ietf.org>; Tue, 12 May 2020 12:50:32 -0700 (PDT)
Received: from DGPREX01.novatec-gmbh.de (unknown [10.60.1.15])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ce-mxgw-01.corbox-factory.de (MTA) with ESMTPS id 49M7h53KJsz1fxCp;
Tue, 12 May 2020 21:50:29 +0200 (CEST)
Received: from DGPREX01.novatec-gmbh.de (10.60.1.15) by
DGPREX01.novatec-gmbh.de (10.60.1.15) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.1913.5; Tue, 12 May 2020 21:50:28 +0200
Received: from DGPREX01.novatec-gmbh.de ([fe80::706f:64b5:2ca3:f5d6]) by
DGPREX01.novatec-gmbh.de ([fe80::706f:64b5:2ca3:f5d6%6]) with mapi id
15.01.1913.007; Tue, 12 May 2020 21:50:28 +0200
From: Falk Andreas <Andreas.Falk@novatec-gmbh.de>
To: Aaron Parecki <aaron@parecki.com>, Francis Pouatcha
<fpo=40adorsys.de@dmarc.ietf.org>, "jim@manicode.com" <jim@manicode.com>
CC: OAuth WG <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] OAuth 2.1 - recalling ROPC
Thread-Index: AQHWKAmaDDrOai3EyUeHHFrfAMH7zKikVwKAgAA7aYCAAA+kAIAALAV6
Date: Tue, 12 May 2020 19:50:28 +0000
Message-ID: <94617b561b934791933f171f5baa51cb@novatec-gmbh.de>
References: <CAOW4vyNY768vqFtxxHXNd2u+VXFoiW=+BG+AJNW0Ee9H13V3zQ@mail.gmail.com>
<77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com>
<CAOW4vyM3Vi4eHCCn1x5-0K0S8pP5qtpTByNYS4DP8EaSqiWn5Q@mail.gmail.com>,
<CAGBSGjrhRpKaG9UdLy+OphSYwPAK7d=kVJNRkkdDV=HHjKMynQ@mail.gmail.com>
In-Reply-To: <CAGBSGjrhRpKaG9UdLy+OphSYwPAK7d=kVJNRkkdDV=HHjKMynQ@mail.gmail.com>
Accept-Language: en-GB, de-DE, en-US
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.3.10]
x-tm-as-product-ver: SMEX-12.5.0.1300-8.5.1020-25414.003
x-tm-as-result: No-9.787900-8.000000-10
x-tmase-matchedrid: pS5owHKhBO2nvGCyBToTI8G0UNgaZpYqGsvgUMYAn4UcI/pZs+xxL9k2
l7i3oc4z/iX1GSpmG6zQACPgtyOvxbMywGOaB4QQMTTrAcDX5/6Oz/LLJUcaHmzd8mVlXGBxigO
Iyyyus7y3lYn7uPqN3l7DLRKN2ZwttE59QbvHf05cod85S7fEgHlUqG5SL+tidqUbKvsokzOsl9
uWwhFOCQ7tM/C2mX98vbg79TmW1OiDAd1DtN1q7SSnuJJeKKeEOYqKF7UrYh4ELMPQNzyJS1l4x
fTSs3QpxCeSAAiLKd5W7tkPKoW8vpCSCROJF+QU+/HV1Dwcb5MpWss5kPUFdOcJOFqc/+CEKKqy
c9Qq8Xr6k6aZQjEVTna6lMSHBJkl7Ma9GYskMp/805SSvoAPN1G//EzLYUavKEB1DAQzrLgA0CO
gL+9tnkSstxDHEhaAskaSx6XaRv81KU/m4Dd2rmhQCsqhuTNinTcLR8+TzEpPQiQvzFiGeFUu4d
MbNIOZykxJ5WoyZKt8rC3hQTP9M3ufZC0Pz+Wk0yPriHnfv3wX2zxRNhh61f/rgj9ncWz9C/G0q
vgJFCcKCu5tN/4WIuPaI7IZzuYe5i92KwhuK4NQ+S0N05fR+0yQ5fRSh265H8jJDe3vPQMwnA4a
zG/gS0PgW7/EUasBCYZljv4C7xopNfI+R65HNZaX2JWUPLy8FcaUNtamWKC/cnIjiwVxREqP1HO
owF+7/yxMakTKjRqtnaVtsWgsS5sO9o0mINopnXRsXMVQ0benLZXtX62Wm+ZMicrOlIVJzwkZgJ
kUx0xq+bvCPQ+6n9QVX76mv7SM9a/ooEbu17CJDLgwb/1K2VkMvWAuahr8zpbY1RnWitda2mNfA
ynaHzp9YAKfEVHAYDX/Rt3LRlKFC0tAij/xpbdTwcNgrWQ+r2m+Pxx43FlPIjqPuNqDzP1xR4mv
sb2o9Mq+4h2A1ApYKVgm72vjJg==
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--9.787900-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.5.1020-25414.003
Content-Type: multipart/mixed;
boundary="_004_94617b561b934791933f171f5baa51cbnovatecgmbhde_"
MIME-Version: 1.0
x-msw-jemd-newsletter: false
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3rTuMz4FgBczLLyXp_Z5xQPuqyc>
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 19:50:36 -0000
> Keep in mind that while the Security BCP explicitly forbids the use of the Password grant in OAuth 2.0, technically OAuth 2.1 just never includes it in the first place. Subtle difference. As RFC 6749 clearly targets third-party applications, ROPC never has been a good fit. It always felt like a bad workaround just for legacy applications. I am primarily looking at OAuth 2.1 from a developer's perspective. Unfortunately, developers often look for a shortcut and the easiest way to implement a required use case. You can find many entries on StackOverflow directing developers to use ROPC instead of a "complicated" redirection flow. Frameworks like Spring Security or Angular clearly follow a "secure by default" approach, this may also be a good direction to follow in future specifications. As Jim already pointed out, I also consider the ROPC being an authentication flow (for trusted first-party applications) and this use case is covered by OIDC. Same as for PKCE an AS may still provide ROPC in an OAuth 2.0 compatibility mode to not break existing apps. That is why I support OAuth 2.1 omitting ROPC. Andreas Falk ________________________________ From: OAuth <oauth-bounces@ietf.org> on behalf of Aaron Parecki <aaron@parecki.com> Sent: 12 May 2020 20:19 To: Francis Pouatcha Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC > We are not talking about ROPC mandating OAuth2, but about OAuth-2.1 forbidding the user of ROPC. Keep in mind that while the Security BCP explicitly forbids the use of the Password grant in OAuth 2.0, technically OAuth 2.1 just never includes it in the first place. Subtle difference. Aaron Parecki On Tue, May 12, 2020 at 10:23 AM Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org<mailto:40adorsys.de@dmarc.ietf.org>> wrote: On Tue, May 12, 2020 at 9:50 AM Jim Manico <jim@manicode.com<mailto: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<mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] OAuth 2.1 - recalling ROPC Francis Pouatcha
- Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC Jim Manico
- Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC Francis Pouatcha
- Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC Jim Manico
- Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC Aaron Parecki
- Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC Falk Andreas
- [OAUTH-WG] Incorporate or Reference RFC8628 Devic… Phillip Hunt
- Re: [OAUTH-WG] Incorporate or Reference RFC8628 D… Aaron Parecki
- Re: [OAUTH-WG] Incorporate or Reference RFC8628 D… Mike Jones
- Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC Francis Pouatcha