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

Dick Hardt <dick.hardt@gmail.com> Wed, 19 February 2020 22:02 UTC

Return-Path: <dick.hardt@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 4FFDB120860 for <oauth@ietfa.amsl.com>; Wed, 19 Feb 2020 14:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_FONT_LOW_CONTRAST=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 3gl5URRNv3VQ for <oauth@ietfa.amsl.com>; Wed, 19 Feb 2020 14:02:22 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 D8C5512083D for <oauth@ietf.org>; Wed, 19 Feb 2020 14:02:21 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id q23so2042117ljm.4 for <oauth@ietf.org>; Wed, 19 Feb 2020 14:02:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A5pMpFscL2GG6xySwD8uR2x3LBbx7lXQfcyjBxws8uU=; b=o3AGDkUnH8+6B5q3EmmW/eHeic1hTek++arv3jTA7Ewh2Aq65khYSt06brKbQXmYBw lqFU3FxSVjLZBEGPVhisRPUsN+JBCls0mol+ZTrQKGZlg+NjjEnXKpxgJhQU04R5PlJY d1JLX0K07uhfiPLfO2xljL+td6R7jan2GmcaObiS2KiMP6+RXM7Bz2APDyZdZC+ZmzWJ mxHYv7vBSD5Lv1SZ5b2UnEfVAlhBYdB01xKlFz4Z8rXQTPnOd2gwQyVfrsEpQUpBEwlc udmeLYFSI/5gtAMltxis26YCvrhdVVLd0LmNlvisEBHNUfoEi6IH8MM3kKy6dr432mWP pV8A==
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=A5pMpFscL2GG6xySwD8uR2x3LBbx7lXQfcyjBxws8uU=; b=fO6w6KBoDEApepi51TRI6YGC5oQbrGoQYV19VUP90EzS4Hx92a9ysL3DV/hja24uBZ lR0zQp0245Y4YzLRLlevJApfsWmppRkFwkI//q93XrrEaA6LvWDpp4J197IeGJ+Ssw6S OWdcbKIo6/2/t8A00I90A7WXRo/wlCXU1vpheDoLLiD95Xx5cl5zAq4snuzfRdKO86Ez sa+hFjQTqhXMwS2JPj/nz0GFPz+f59fcSAMk73xG4vAemwFUv7rzskrB/pk/3bCPnffF csd/do3yyit1ppHer+orane1aGQHFP1JDwVHsBatsj+EnqFuHyKAQnwFknZpG2ly8CtU vV9g==
X-Gm-Message-State: APjAAAVZAi+gA44u0nbxwYM4uHNJiKwy8fmPMQIUbPMMgy71Gv6i18Wg 94juSu83wB1N7mmfFKxPPnpEQ0Q5htwHntz/PVF2yej8
X-Google-Smtp-Source: APXvYqwAksb/cHZ18HbVGiM6S3IvFaeUQJFaTSDFNgNw+HilgUNh7jC3kUejUhiDBeNX+5plFSDnZNXrvqg9QKLnEz0=
X-Received: by 2002:a2e:808a:: with SMTP id i10mr16868651ljg.151.1582149739974; Wed, 19 Feb 2020 14:02:19 -0800 (PST)
MIME-Version: 1.0
References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <E37187C7-9DD0-4C3B-990D-55CB8C39BD21@forgerock.com>
In-Reply-To: <E37187C7-9DD0-4C3B-990D-55CB8C39BD21@forgerock.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wed, 19 Feb 2020 14:01:53 -0800
Message-ID: <CAD9ie-trV02ifD8HU1JQ-FDS0=eLnikM7SWfd1hSHkn5_3m03Q@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, Anthony Nadalin <tonynad=40microsoft.com@dmarc.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003b981d059ef4f1c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bODCgn5kFVL58OLaNXAufk4-dSY>
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 22:02:26 -0000

Neil: are you advocating that password grant be preserved in 2.1? Or do you
think that service account developers know enough about what they are doing
to follow what is in 6749?
ᐧ

On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <neil.madden@forgerock.com>
wrote:

> OAuth2 clients are often private to the AS - they live in a database that
> only the AS can access, have attributes specific to their use in OAuth2,
> and so on. Many existing systems have access controls based on users,
> roles, permissions and so on and expect all users accessing the system to
> exist in some user repository, e.g. LDAP, where they can be looked up and
> appropriate permissions determined. A service account can be created inside
> such a system as if it was a regular user, managed through the normal
> account provisioning tools, assigned permissions, roles, etc.
>
> Another reason is that sometimes OAuth is just one authentication option
> out of many, and so permissions assigned to service accounts are preferred
> over scopes because they are consistently applied no matter how a request
> is authenticated. This is often the case when OAuth has been retrofitted to
> an existing system and they need to preserve compatibility with already
> deployed clients.
>
> See e.g. Google cloud platform (GCP):
> https://developers.google.com/identity/protocols/OAuth2ServiceAccount
> They use the JWT bearer grant type for service account authentication and
> assign permissions to those service accounts and typically have very broad
> scopes. For service-to-service API calls you typically get an access token
> with a single scope that is effectively “all of GCP” and everything is
> managed at the level of permissions on the RO service account itself. They
> only break down fine-grained scopes when you are dealing with user data and
> will be getting an access token approved by a real user (through a normal
> auth code flow).
>
> — Neil
>
> > On 19 Feb 2020, at 21:35, Torsten Lodderstedt <torsten@lodderstedt.net>
> 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 <neil.madden@forgerock.com>:
> >>
> >> 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 <hans.zandbelt@zmartzone.eu>
> 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 <aaron@parecki.com>
> 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 <jricher@mit.edu> 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 <tonynad=
> 40microsoft.com@dmarc.ietf.org> 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 <oauth-bounces@ietf.org> 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
>