Re: [OAUTH-WG] OAuth 2.1: dropping password grant
Matthew De Haast <matt@coil.com> Fri, 21 February 2020 13:41 UTC
Return-Path: <matt.dehaast@coil.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 ACF821200E7 for <oauth@ietfa.amsl.com>; Fri, 21 Feb 2020 05:41:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=coil.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 D17cJAkFPp4S for <oauth@ietfa.amsl.com>; Fri, 21 Feb 2020 05:41:53 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 64B7D12081A for <oauth@ietf.org>; Fri, 21 Feb 2020 05:41:53 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id g19so2348666eds.11 for <oauth@ietf.org>; Fri, 21 Feb 2020 05:41:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coil.com; s=g; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=e8o4ehQRxjtHeIpmXld8imyIfX5Un7vbOJRis9jo4BA=; b=EDPAIten2OP7gNsSBwT+u/UFcHKZzu0onK99pwOk3JOTvjJjHRlHVzqbAz1sR3oi3p Hv5Mvz2ErubBC3DPMpKTYcHMs4wV4EnFpYhoV4lQ7OJWy49pjNg4qJ6ERmlbrJi1lBoQ g+4llwPF3pwLJjJn5HWxYbL7zNmP6w+ZCH28fPrGxOfH61yKQUz61VS52QO1Es6Wl2Ui +rBMv/0r7xtqx+tfj32pkwGjckZ+micC/5VMJgtZiy937+r4yL+hrxRUbQuNmEA3d0mq +izl0YV7/16yx/EnOriyutbq5xBHI3+YdSpQ3r+jD2Of2R76oOvcYw4Jw083qor5FsdR H5Ew==
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; bh=e8o4ehQRxjtHeIpmXld8imyIfX5Un7vbOJRis9jo4BA=; b=k/u3x+/tp1vi95jvmgAKE1atvdiUxXtG2mOe/k5c6nS4pq+LL7a8L0w9CtHvPNzU4d Zp9TeoIpGThU3Ou5Gw9z7XM8LCVNFX6uzw7wxa5V5l8r8zlPQbIuM9q54dxDwThld1B5 X34/da3FF+Xr5UJ2dl5bZWPVBXrXXzYhQ1mXlPbQJt1G5U86tCeOxlg5nrDuHT1W8YkR 001Ve8+sh3svKK6kvPkuFs9uXIXJoBth48/97Eze2JpJnjtOqX8pqp3h6OlA23zHIfwy Ja2XN05ozQ4zvaRONB77UOdbPu5OWDHdUmLNGYZwCMaGHDvF9pKccYe/gQN3pLVm5tmH vzyQ==
X-Gm-Message-State: APjAAAXXoHuamol6PrWs/D6PmIoX+dzntYzlWpqub0594jrHwZxEyKv9 ISWUSFh3+C7oq5NC6NP0hcpPufeVEhkDA/dHbVoqoQzgU3Y=
X-Google-Smtp-Source: APXvYqzSXuh8bylscRHPP5F5GPBgPZ/mAKHsdD1HgTIe34cMMZaILSAiWGgXB+0FFujvZaoE2QhwazFCG7eGcEyNE1o=
X-Received: by 2002:a17:906:3798:: with SMTP id n24mr35560023ejc.15.1582292511378; Fri, 21 Feb 2020 05:41:51 -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> <CAD9ie-trV02ifD8HU1JQ-FDS0=eLnikM7SWfd1hSHkn5_3m03Q@mail.gmail.com> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com>
In-Reply-To: <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com>
From: Matthew De Haast <matt@coil.com>
Date: Fri, 21 Feb 2020 15:41:36 +0200
Message-ID: <CANsTMfEAoOa6ts8xPc5eZi+D09EOC11-07uUq9R5gD425EbUJg@mail.gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000125ff4059f162f61"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/izEcvyWNVYHin3gz-suuSdkz_Og>
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: Fri, 21 Feb 2020 13:41:57 -0000
> > I have a feeling that if we had more concise JWT libraries and command > line tools, where using the JWT Bearer grant became a one-liner again then > we wouldn’t be having this conversation. So perhaps removing it is an > incentive to make that happen. > Neil could you elaborate more on this please. What failures are you currently experiencing/seeing with the JWT Bearer grant? Matt On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <neil.madden@forgerock.com> wrote: > I have a feeling that if we had more concise JWT libraries and command > line tools, where using the JWT Bearer grant became a one-liner again then > we wouldn’t be having this conversation. So perhaps removing it is an > incentive to make that happen. > > > > On 19 Feb 2020, at 22:01, Dick Hardt <dick.hardt@gmail.com> wrote: > > > > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] OAuth 2.1: dropping password grant Dick Hardt
- Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping pas… Anthony Nadalin
- Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping pas… Dick Hardt
- Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping pas… Justin Richer
- Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping pas… Phillip Hunt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Aaron Parecki
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Hans Zandbelt
- Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping pas… Dick Hardt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Brock Allen
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Richard Backman, Annabelle
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Dick Hardt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Matthew De Haast
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Levi Schuck
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Richard Backman, Annabelle
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Justin Richer
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Richard Backman, Annabelle
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Dick Hardt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Phillip Hunt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Brian Campbell
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant William Denniss
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant William Denniss
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Aaron Parecki
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant lanerashaad80@gmail.com
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Neil Madden
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Dick Hardt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Dominick Baier
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Phillip Hunt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Dick Hardt
- Re: [OAUTH-WG] OAuth 2.1: dropping password grant Justin Richer