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

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 21 February 2020 15:25 UTC

Return-Path: <torsten@lodderstedt.net>
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 CEE99120840 for <oauth@ietfa.amsl.com>; Fri, 21 Feb 2020 07:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lodderstedt.net
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 6zqm1FL0lQmS for <oauth@ietfa.amsl.com>; Fri, 21 Feb 2020 07:25:11 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 4296112083E for <oauth@ietf.org>; Fri, 21 Feb 2020 07:25:11 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id u6so2525067wrt.0 for <oauth@ietf.org>; Fri, 21 Feb 2020 07:25:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bVrks8MT5wscA6RCKyyZq7fls16NWnRC8YDZKKH4tbg=; b=ks2MH5IevWEuS/fFKF252OE3+VNR119h63Iu9D108M3aZnczKU3fgkMAPM3NL5RDFu XTCATwS5uVFXR5DaQd/9QeAKUZg+lJFWP8cFowlJbYAYWRsrRBDPpPChlikUYOcLHL7u PhdwYGREHmcbsobpz2crl0isBljvaiTJPP+Bz0jAGsph5Fm8OeOuspysEYMeo+9W5e9z U3cOkw0b17zt10unQ7sC7uJr37mTesZ/5KJajvHKiQhCeCT4I+FQMEIkNaUTVpd11Xqd 2aoXc5JE9zx+eAV2k1PgTpPyGYa2hche2x6n0aQGhjtvA1Z7HnG3pr8YwxIK18D0iqbf IUcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bVrks8MT5wscA6RCKyyZq7fls16NWnRC8YDZKKH4tbg=; b=gMpfuSU25zTShWx7KoB3jgvlGMt6YzSy/li71ZO6oBGKbRiF+1c17DRVOf0FWj9H63 E8sWSXogyvFFo7FJUFh06XSig7HEYOPUtMJVz2Mqob/zyXqZKaNyevBn48alftUXb+rV xxQY+Kx/weFO9B83jc2qsvEcH9biyXc1UUjz62vlh0yx+6pMPl4AiKZLRv9OuG8MVuZx nBxvDI8JQfzUEd6RLvfFGG2nLUX5h4hUSrBQcEOewL5/o8TVDAB74O8Xg9TuZ1R5eaQC DgvmWmJXUwgaC0fCZLTS9qXFHmWREM61yBC1jo5T8Jx5+73i4lva+hChtx1wN+mw5Yg/ LpsQ==
X-Gm-Message-State: APjAAAVFsyjKReC6cfYt53zwGAY3fhjT+863A4O8RwCKce6cVj8I0t4v Z2AfHcKvFuqUtn+p1XhHuCXLzA==
X-Google-Smtp-Source: APXvYqy+yRkHzYCDoO17w6qdHFWc3MpJRqTquETsIuoLCQ41EVdCuCxlrhq5KF9NrwqQsBdT52P8qA==
X-Received: by 2002:adf:fac7:: with SMTP id a7mr21594443wrs.299.1582298709436; Fri, 21 Feb 2020 07:25:09 -0800 (PST)
Received: from [192.168.71.111] (p5B0D94B9.dip0.t-ipconnect.de. [91.13.148.185]) by smtp.gmail.com with ESMTPSA id c9sm4429287wrq.44.2020.02.21.07.25.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 07:25:08 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <13BE5936-399A-49CE-B4F5-4F72508112BF@forgerock.com>
Date: Fri, 21 Feb 2020 16:25:07 +0100
Cc: Matthew De Haast <matt=40coil.com@dmarc.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0888934B-D011-41FC-9701-60D4B1C7FE53@lodderstedt.net>
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> <1094FB21-0466-4212-9310-CB2A7755F683@lodderstedt.net> <13BE5936-399A-49CE-B4F5-4F72508112BF@forgerock.com>
To: Neil Madden <neil.madden@forgerock.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1qm0N9sz7tUiSrREFSCvkLKrOhQ>
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 15:25:15 -0000

It’s difficult to give advise without lot of detailed information. I nevertheless give it a try.

Mechanically, the application would need to use a different grant, credential instead of ROPC. If such an application today already uses a distinct client_id, the AS must be set up to relate this client_id and the service account the same app used before directly. With that the respective deployment is able to leverage all client authentication methods, including mTLS.

> On 21. Feb 2020, at 16:02, Neil Madden <neil.madden@forgerock.com> wrote:
> 
> But we’re talking about existing deployments. Are you suggesting that people should bulk rename all of their clients to match the service accounts (or vice-versa)? 
> 
> — Neil
> 
>> On 21 Feb 2020, at 14:54, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> 
>> 
>> 
>>> On 21. Feb 2020, at 15:47, 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.
>> 
>> I don’t see this as a fundamental change, it adds another claim/permission source to a client id.
>> 
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13
>> 
>> This can be solved by either using the id of the service account as sub or even put the service identity into a dedicated realm. We implemented the later strategy at Deutsche Telekom couple of yrs ago.
>> 
>>> 
>>> — 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>:
>>>>>>>>>>> 
>>>>>>>>>>> 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
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>