Re: [OAUTH-WG] OAuth 2.1: dropping password grant

"Brock Allen" <brockallen@gmail.com> Wed, 19 February 2020 21:43 UTC

Return-Path: <brockallen@gmail.com>
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 A20F4120289 for <oauth@ietfa.amsl.com>; Wed, 19 Feb 2020 13:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xDhESLXKflvK for <oauth@ietfa.amsl.com>; Wed, 19 Feb 2020 13:43:21 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 0B8CE120128 for <oauth@ietf.org>; Wed, 19 Feb 2020 13:43:21 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id l21so1384439qtr.8 for <oauth@ietf.org>; Wed, 19 Feb 2020 13:43:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=G5Zs8TS0ltL9l8FHpptNSnxxBnw7aTO9dUMCAK/yvH4=; b=CYUCorwd1QeT/lIQRl0tB4n9LOW0YG5KoHEwc6hk+YziiOcT7jDvYylZoUh97+IEFw LF8V5opxqZmhs6zm70hR7xZcTFBjQYMFjaUon73LFu3viauonJwJAu45fnR5UY3ShHyS Eo7V/Vhd2Ceg+bJNnRb7JQAV0H7z264vK9QfWOGO2VJlD34FkB11ZQr2MTAJE6H3Skod DKb4gu5R4uz0ZC7Nklder2TXEq3VENxYwgjjTP3smli6kCdh+26b9qazsScl2hKAdJCf mEHsO8K4BYvzwgdr/ZA1azua9YjHSoMAeqY80g03cSh26SUR8op5ulwAmUd4RN0IiRah nrkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=G5Zs8TS0ltL9l8FHpptNSnxxBnw7aTO9dUMCAK/yvH4=; b=BBx8v00nbiO2FZJT4GlZ047CFprK2ryPTda8Pd+mhXBE3z9IFHND2sjibRI2ueR4z7 QtOj6HdkOKkocM7E5/63XnnAeByvrRrPQNX5dk91ntDdweYXIbVOygbX2TsqLJG6Unrd NcWUAeEG0EjMFKNZwC/v0V0NE4yjtLaI4rfi+IhrBVA0Q0DmBN3jqBTsGhM0Z+99uSY/ XLNS5G4XukEEoy02bHB2+bntRRS8CwYTK6/tCHDWpjXSmeJ1ek326Qt2WwQrL8FEnqrT +CKYUvcoBgXgx3jlZUCMnwoMgFkpNaD7WxXX0EsOB3zCS6ui4u06junynVSkiQZFICO/ tidA==
X-Gm-Message-State: APjAAAVuBgPrqA2cAMIrAwShHrwVLMH9pm1l42XvvHmGXnwh8e0DEGRp LM4bi5T6g4qd8VYhpnFNPBw=
X-Google-Smtp-Source: APXvYqxs3dX9jf4CSq13fdYW/R3ZjSZ74hd7lHDeEmp+XUdTkPG7qOXfIqOcmLn1ORzhhxJr+MzOZQ==
X-Received: by 2002:ac8:a06:: with SMTP id b6mr24697803qti.264.1582148599870; Wed, 19 Feb 2020 13:43:19 -0800 (PST)
Received: from [10.0.1.2] (pool-74-103-207-160.prvdri.ftas.verizon.net. [74.103.207.160]) by smtp.gmail.com with ESMTPSA id l19sm516755qkl.3.2020.02.19.13.43.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2020 13:43:19 -0800 (PST)
Content-Type: multipart/alternative; boundary="----=_NextPart_39244167.964375144273"
MIME-Version: 1.0
Date: Wed, 19 Feb 2020 16:43:18 -0500
Message-ID: <Mailbird-db7f7ccb-1ce0-4d20-83c2-3b817dfa652f@gmail.com>
From: "Brock Allen" <brockallen@gmail.com>
To: "Torsten Lodderstedt" <torsten=40lodderstedt.net@dmarc.ietf.org>, "Neil Madden" <neil.madden@forgerock.com>
Cc: "Anthony Nadalin" <tonynad=40microsoft.com@dmarc.ietf.org>, "" <oauth@ietf.org>
In-Reply-To: <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net>
References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net>
User-Agent: Mailbird/2.7.14.0
X-Mailbird-ID: Mailbird-db7f7ccb-1ce0-4d20-83c2-3b817dfa652f@gmail.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zzlc-oKiLrOhCWXqn5e6vtWT-6I>
Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant
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: Wed, 19 Feb 2020 21:43:24 -0000

I've seen the same. People have user-centric authorization systems where they have a "service user" that they attach permissions to. In client credentials they don't want to have to special case a client credentials caller (vs. a code flow client) and instead just use the calling "user" to look up permissions.


-Brock

On 2/19/2020 4:35:43 PM, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
Can you explain more in detail why the client credentials grant type isn’t applicable for the kind of use cases you mentioned?

> Am 19.02.2020 um 22:03 schrieb Neil Madden :
>
> I very much agree with this with regards to real users.
>
> The one legitimate use-case for ROPC I’ve seen is for service accounts - where you essentially want something like client_credentials but for whatever reason you need the RO to be a service user rather than an OAuth2 client (typically so that some lower layer of the system can still perform its required permission checks).
>
> There are better grant types for this - e.g. JWT bearer - but they are a bit harder to implement. Having recently converted some code from ROPC to JWT bearer for exactly this use-case, it went from a couple of lines of code to two screens of code. For service to service API calls within a datacenter I’m not convinced this resulted in a material increase in security for the added complexity.
>
> — Neil
>
>> On 18 Feb 2020, at 21:57, Hans Zandbelt wrote:
>>
>> I would also seriously look at the original motivation behind ROPC: I know it has been deployed and is used in quite a lot of places but I have never actually come across a use case where it is used for migration purposes and the migration is actually executed (I know that is statistically not a very strong argument but I challenge others to come up with one...)
>> In reality it turned out just to be a one off that people used as an easy way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
>>
>> Hans.
>>
>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote:
>> Agreed. Plus, the Security BCP is already effectively acting as a grace period since it currently says the password grant MUST NOT be used, so in the OAuth 2.0 world that's already a pretty strong signal.
>>
>> Aaron
>>
>>
>>
>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote:
>> There is no need for a grace period. People using OAuth 2.0 can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
>>
>> — Justin
>>
>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin wrote:
>>>
>>> I would suggest a SHOULD NOT instead of MUST, there are still sites using this and a grace period should be provided before a MUST is pushed out as there are valid use cases out there still.
>>>
>>> From: OAuth On Behalf Of Dick Hardt
>>> Sent: Tuesday, February 18, 2020 12:37 PM
>>> To: oauth@ietf.org
>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant
>>>
>>> Hey List
>>>
>>> (Once again using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on)
>>>
>>> In the security topics doc
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4
>>>
>>> The password grant MUST not be used.
>>>
>>> Some background for those interested. I added this grant into OAuth 2.0 to allow applications that had been provided password to migrate. Even with the caveats in OAuth 2.0, implementors decide they want to prompt the user to enter their credentials, the anti-pattern OAuth was created to eliminate.
>>>
>>>
>>> Does anyone have concerns with dropping the password grant from the OAuth 2.1 document so that developers don't use it?
>>>
>>> /Dick
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> --
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> --
>> hans.zandbelt@zmartzone.eu
>> ZmartZone IAM - www.zmartzone.eu
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth