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

Levi Schuck <levi.schuck@gmail.com> Fri, 21 February 2020 14:50 UTC

Return-Path: <levi.schuck@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 1D4EE120895 for <oauth@ietfa.amsl.com>; Fri, 21 Feb 2020 06:50:22 -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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 nbeU3cC1btcv for <oauth@ietfa.amsl.com>; Fri, 21 Feb 2020 06:50:17 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 99169120879 for <oauth@ietf.org>; Fri, 21 Feb 2020 06:50:17 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id b7so2016078qkl.7 for <oauth@ietf.org>; Fri, 21 Feb 2020 06:50:17 -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=7RgttRCF/1jWODR81FQSn2UZ/RIwyf4PJ1xK4fLNkBc=; b=QUINVRKTX29rB2CKBEJutpQ96fx2iZFExY/Po7g45BillmVSfOx5Z3vc00U0es9HmM gPOG48taaVR5+PecPNQvCckJ8V+LhgIyBegl0pePRiFR5OHxdFhOUszFXgNth812D1nF TXo+JFO/PG/wVSha585UNPB2M9jAhlxJrEjNSzgRKCM/+f3WSteg973MVAr8UjGnzTIg h/klYRbCT+EwKDuiy1BfvsvO/yWwSROntB0Y6fDJcLijy3q6PvYcVwn4pAvd2gGeUR4G E7wiZJc6v6wNOD4mFbaZ3qcjKg1TQrV2VBtkLe6OkUOVXSPeg/xcHF1EBG3Zw80vOasn OFZA==
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=7RgttRCF/1jWODR81FQSn2UZ/RIwyf4PJ1xK4fLNkBc=; b=ewvJ+3S3vAnnGJl5ty0Z9dEzI40TvX10g6TlKAptngLHiauOzkkTjQhSlndrYOd45P y4bMoKVVknTlGy1HnOc9xAzNfbED7PmlRoP+GhZ1UZgKmL6Z825MgqOvq4yA6vmZxJ8H ADiZA6w0NJMQHQ0SpHGB+gNKDU4YRsgGv/GV7Bf1datT8qouQ2LYa5PCI6FYsZVrFykI wmVnSXqBnyk8VStTsjDlAuPI8W2MgA04WyQnjyol7CJdVlNF9tN//z1eZyFov+9qmq+p kRmnkgS+ayZ9iTeai79+Sxn4Dvtc19onWz+zTS0xxCoPgrZqQyoheYw/++Vnw5ODFJI1 ZzaQ==
X-Gm-Message-State: APjAAAXVrVL+V6GNARzVnhR0E2ft1yCAclfQC+amkAbwiDVpk34CtKwh gjh8OF0YbQ+3V3Klhd9omXdP8lB41SYlXhLgI68=
X-Google-Smtp-Source: APXvYqxFsQtmr8IYH6yH/4gB6bhtFvyEnhsTBsX68hByQ68GVMfirUH0xBCtwZVHwO3u6thBKfmBLw8dcGKT/6uD0uk=
X-Received: by 2002:a37:9647:: with SMTP id y68mr33160730qkd.300.1582296616677; Fri, 21 Feb 2020 06:50:16 -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> <CANsTMfEAoOa6ts8xPc5eZi+D09EOC11-07uUq9R5gD425EbUJg@mail.gmail.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <AAE487F7-776C-472B-B6DF-CB60D434F95A@forgerock.com>
In-Reply-To: <AAE487F7-776C-472B-B6DF-CB60D434F95A@forgerock.com>
From: Levi Schuck <levi.schuck@gmail.com>
Date: Fri, 21 Feb 2020 08:50:05 -0600
Message-ID: <CAF=kGtdxuVn2ZQX==m8gUEORi9NpOfcujeGj0oguzvh6zpx13A@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Matthew De Haast <matt=40coil.com@dmarc.ietf.org>, Torsten Lodderstedt <torsten@lodderstedt.net>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c434bb059f1723a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/jUqBf_iBeTA2daB-lePHYoV2VGY>
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 14:50:33 -0000

Hello,

I am new to the mailing list.
I support a mTLS grant type.

Client certificate and additional credentials in the request seems
redundant.

While using GCP, the flow seems to be signing a JWT with a private key
known to google, which is then exchanged for a google signed JWT. Beyond
the service account name being included in the JWT, there are no other
credentials exchanged. This flow matches what I read in 7523.

However, the GCP service account JWT exchange also carries the declared
scopes the service account may use. The AS seems to validate these scopes
before issuing a google signed JWT.

Perhaps a mTLS grant exchange can use alg: none as a JWT for a client
assertion, as JWTs already have conventions to include scopes. Or have
another assertion type altogether.

-Levi

On Fri, Feb 21, 2020 at 8:47 AM Neil Madden <neil.madden@forgerock.com>
wrote:

> Sorry, I missed that message.
>
> While this may be a solution in specific circumstances, I don’t think it’s
> a general solution. e.g. an AS may not allow manually choosing the
> client_id to avoid things like
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13
> or may return different introspection results for client credentials tokens
> (e.g. with no “sub”) and so on. In practice, this adds even more steps for
> somebody to migrate from existing ROPC usage.
>
> This is asking people to make fundamental changes to their identity
> architecture rather than simply switching to a new grant type.
>
> — Neil
>
> > On 21 Feb 2020, at 14:34, Torsten Lodderstedt <torsten@lodderstedt.net>
> wrote:
> >
> > I see - we have gone full cycle :-)
> >
> > Annabelle’s proposal would solve that. Relate a client id to a service
> account and obtain the token data from there.
> >
> >> On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@forgerock.com>
> wrote:
> >>
> >> Yes, that is great. But mTLS doesn’t support service accounts (!=
> clients). Maybe it should? Should there be a mTLS *grant type*?
> >>
> >> — Neil
> >>
> >>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt <torsten@lodderstedt.net>
> wrote:
> >>>
> >>> Have you ever tried the client credentials grant with mTLS? After
> reading your description it seems to be simpler than JWT Bearer.
> >>>
> >>> * work out if the AS even supports mTLS
> >>> * work out how to configure the AS to trust my cert(s)
> >>> * Create key pair and cert using openssl
> >>> * Register your (self-signed) cert along with your client_id
> >>> * Configure the HTTP client to use your key pair for TLS Client
> Authentication
> >>>
> >>> Works very well for us.
> >>>
> >>>> On 21. Feb 2020, at 15:12, Neil Madden <neil.madden@forgerock.com>
> wrote:
> >>>>
> >>>> No failures, but it is a much more complex grant type to set up, when
> you consider everything you have to do:
> >>>>
> >>>> * work out if the AS even supports JWT bearer and how to turn it on
> >>>> * work out how to configure the AS to trust my public key(s)
> >>>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
> >>>> * determine the correct settings for issuer, audience, subject, etc.
> Does the AS impose non-standard requirements? e.g. RFC 7523 says that the
> JWT MUST contain a “sub” claim, but Google only allows this to be present
> if your client is doing impersonation of an end-user (which requires
> additional permissions).
> >>>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones
> might not) If I do, can I reuse the JWT or must it be freshly signed for
> every call?
> >>>> * locate and evaluate a JWT library for my language of choice.
> Monitor that new dependency for security advisories.
> >>>> * choose a suitable signature algorithm (‘ere be dragons)
> >>>> * figure out how to distribute the private key to my service
> >>>>
> >>>> Compared to “create a service account and POST the username and
> password to the token endpoint” it adds a little friction. (It also adds a
> lot of advantages, but it is undeniably more complex).
> >>>>
> >>>> — Neil
> >>>>
> >>>>
> >>>>> On 21 Feb 2020, at 13:41, Matthew De Haast <matt=
> 40coil.com@dmarc.ietf.org> 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.
> >>>>>
> >>>>> 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>gt;:
> >>>>>>>>
> >>>>>>>> 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 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
>