Return-Path: 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 E7F343A0D3B for ; Sun, 1 Mar 2020 03:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=leastprivilege-com.20150623.gappssmtp.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 xxZSb2OfLbnd for ; Sun, 1 Mar 2020 03:09:03 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 C65573A0D3A for ; Sun, 1 Mar 2020 03:09:02 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id q18so7368818qki.10 for ; Sun, 01 Mar 2020 03:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=vIBoNQ+9jYhFkoy69lzM8phQVwezbW92ohOUNTcoyLc=; b=KFT7wxwaXtQY2qYShb93X9kuzThctJsziOHQPz3yVK6LO4cIFoXueYp0/6IuCru5By YRy7/74vGntSV/C3cSupe1aJMCZDaYIICWLMF4WEB+70ReCOT9NHMmRsenZrqnoHP+TM rAxWxEsd+iMHylet3KjYBcmf5dy40vsa55RbB6r4j+xzqFHPLgrxobzmsIC5LF59zCI8 i/4++PN1VOOG4FlcL2TLxsTYP3r1m+L+LRSrv6qMat1anU8kwBa+oLpmKDMYkBz1Ed4W EMlkSN5Bysu9swSOEWND4ZHyJJSWamJQy4Wn/ARsXkuRTmYS02jwYEZj+Ryy92G83KRn Ztmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=vIBoNQ+9jYhFkoy69lzM8phQVwezbW92ohOUNTcoyLc=; b=LKLCGmYAfWHewWvxes29zSPZmU1hzncCtH85FBtd7Q3j7gC3mh+r+e9e0rTVgI4UTC /2rBOXmp6E4ZOj2fzWTs3K7JZXtodNOSnPCGmx1ROvSRH7ZQLKVi0nndDKJp/HNvV9Zb 2HvsIwNzMreTxush9XWHq8HNhH3R8vKSwQZ6/kE4WB2Rat2hbMce+jmK9gNAHrPnY8Ae dFYzVUqHMf6WAl+Hp40/2Do0jX5azJSZPyLGyIh/wsaZMrSrh9Vgu/jClQ661FwN3Xy7 3YnGi7yJc3taUHkFKxq76Sjfr74Yxw6JLywqNLYqtOsp+9epM+Q7iCFEa8Mio/maKQDo AOGA== X-Gm-Message-State: APjAAAVU6IomwNRDJIxynyOVULtn6GMF/O0klDnjRBy5F2IJ8lmE4NSu ez1R2b4EENS4Xy9FSFazJiz3zhB2V0Gdz84EdGg+ X-Google-Smtp-Source: =?utf-8?q?APXvYqxtYVM+zsauAkn1z6HFzKKj+sUyUvfmSw9Zex9e?= =?utf-8?q?h7W9EEh5+zGmJgCBR8bS9ewgnv3+RksyjccXy3+lCeeeJwk=3D?= X-Received: by 2002:a37:9683:: with SMTP id y125mr12128424qkd.450.1583060940806; Sun, 01 Mar 2020 03:09:00 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 1 Mar 2020 03:09:00 -0800 From: Dominick Baier In-Reply-To: References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.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> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <045164C6-685B-45FE-A6F6-0E15DBD5FE08@mit.edu> <5820B70D-1935-4A78-BD53-42AC2DF36336@forgerock.com> <3aa0ac2f-f480-4054-974c-cf468f6070be@Spark> MIME-Version: 1.0 Date: Sun, 1 Mar 2020 03:09:00 -0800 Message-ID: To: Dick Hardt , Nat Sakimura Cc: "Richard Backman, Annabelle" , Brian Campbell , "oauth@ietf.org" , Matthew De Haast Content-Type: multipart/alternative; boundary="00000000000008ead6059fc919e7" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2020 11:09:10 -0000 --00000000000008ead6059fc919e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2) write an OAuth 2.1 extension for service account grants. (the grant type could continue to be "password", but now clearly in the context of a service account in a different document) IMHO - if such a thing gets defined, it should be a separate document. Keep 2.1 as simple as possible. =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 28. February 2020 at 22:04:10, Dick Hardt (dick.hardt@gmail.com) wrote: It looks like there is consensus to remove ROPC for a user -- but that the password grant is not a bad practice for service accounts. That leads to providing clarity on service accounts. 1) add service account grant to the OAuth 2.1 document 2) write an OAuth 2.1 extension for service account grants. (the grant type could continue to be "password", but now clearly in the context of a service account in a different document) With the goal of OAuth 2.1 being a capture of all the best practices, (2) makes more sense as it could discuss all aspects of service accounts including mapping a client to a service account. What do others think? =E1=90=A7 On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura wrote: > Let us do it then and deprecate ROPC. > There definitely are use-cases that need this pattern around me as well, > but we are using JWT bearer grant instead. Standardizing the behavior is > good. I am fine with new service_account grant type as well, btw. > > Nat > 2020=E5=B9=B42=E6=9C=8825=E6=97=A5 20:41 +0900=E3=80=81Neil Madden =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > I=E2=80=99d be open to defining a new service_account grant type and > removing/deprecating the ROPC grant. I=E2=80=99d also be happy if we just= said that > service account flows should use the JWT bearer grant, and we document th= e > best practices around that and encourage client libs to implement support > for it. > > Should there be a dedicated draft for best practices for > service-to-service usage? > > =E2=80=94 Neil > > On 25 Feb 2020, at 00:13, Aaron Parecki wrote: > > I think we might be going about this discussion the wrong way. > > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > Concur with the sentiment expressed by Neil here. > > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden > wrote: > I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be > doing=E2=80=9D unless we have concrete security or interoperability reaso= ns for > doing so. > > I 100% agree that the job of a standard is not to tell people "what they > ought to be doing". Instead, a standard is more about documenting the > current state of the art as deployed in existing implementations. > > With that in mind, I think that leaves us with two concrete problems with > the password grant: > > 1) The actual problem with the password grant is end users entering > passwords in applications, which the group (mostly) agrees on > 2) People are re-appropriating the password grant for things like service > accounts or backends that are inflexible, not actually using it for end > user credentials > > So it seems like there's actually something missing from OAuth which is > leading people to find the password grant and use that because it's the > only thing that most closely fits their existing model. It seems like we'= d > be better off defining a new extension that captures the use case people > are actually doing, instead of encouraging the continuing use of the > password grant for this purpose. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > Concur with the sentiment expressed by Neil here. > > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden > wrote: > I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be > doing=E2=80=9D unless we have concrete security or interoperability reaso= ns for > doing so. > > I also don=E2=80=99t agree that people doing this are doing anything wron= g. I > don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve l= earnt over the > years not to second-guess their reasons for doing it. > > Are Google wrong for using the JWT bearer grant (not client credentials) > and service accounts? They even go so far as to say =E2=80=9Cscopes are n= ot a > security mechanism=E2=80=9D [1] and tell people to use service account ro= les > instead. (Precisely because they also support non-OAuth auth methods, whi= ch > bypass any scopes). > > Are we really going to tell them to rewrite it all to use the client > credentials grant? > > [1]: > https://cloud.google.com/compute/docs/access/service-accounts#accesscopes= iam > > On 21 Feb 2020, at 21:04, Justin Richer wrote: > > +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, and = it=E2=80=99s time > to get rid of it and send people toward what they really ought to be doin= g. > > Another thing I=E2=80=99ve seen is using different service accounts to ge= t > different sets of access for one client =E2=80=94 if you=E2=80=99re doing= that, you=E2=80=99ve got > a client pretending to do two different things, or your APIs should be > using scopes to differentiate access instead of client/user identity. > > =E2=80=94 Justin > > On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > The client IDs can still be opaque identifiers provided by the AS, they > just happen to be associated with specific service accounts. Or they coul= d > be the opaque IDs that the AS already issued for the service account. > Either way, the AS could issue a token with the appropriate subject and > other claims for the service account. > > If your client identity is bound to a specific service account identity > (i.e., the resource owner), then ROPC reduces down to Client Credentials. > What's the point in passing two identifiers and two credentials for the > same identity? > > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > > > =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" < > oauth-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote: > > Sorry, I missed that message. > > While this may be a solution in specific circumstances, I don=E2=80=99t t= hink it=E2=80=99s > 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 toke= ns > (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds ev= en 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.. > > =E2=80=94 Neil > > On 21 Feb 2020, at 14:34, Torsten Lodderstedt > wrote: > > I see - we have gone full cycle :-) > > Annabelle=E2=80=99s proposal would solve that. Relate a client id to a se= rvice > account and obtain the token data from there. > > On 21. Feb 2020, at 15:31, Neil Madden wrote: > > Yes, that is great. But mTLS doesn=E2=80=99t support service accounts (!= =3D > clients). Maybe it should? Should there be a mTLS *grant type*? > > =E2=80=94 Neil > > On 21 Feb 2020, at 14:20, Torsten Lodderstedt > 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 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 =E2=80=9Csub=E2=80=9D claim, but Google only allows this t= o be present if > your client is doing impersonation of an end-user (which requires > additional permissions). > * do I need a unique =E2=80=9Cjti=E2=80=9D 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 (=E2=80=98ere be dragons) > * figure out how to distribute the private key to my service > > Compared to =E2=80=9Ccreate a service account and POST the username and p= assword > to the token endpoint=E2=80=9D it adds a little friction. (It also adds a= lot of > advantages, but it is undeniably more complex). > > =E2=80=94 Neil > > > On 21 Feb 2020, at 13:41, Matthew De Haast > 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 the= n > we wouldn=E2=80=99t be having this conversation. So perhaps removing it i= s 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 > 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 the= n > we wouldn=E2=80=99t be having this conversation. So perhaps removing it i= s an > incentive to make that happen. > > > On 19 Feb 2020, at 22:01, Dick Hardt 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? > =E1=90=A7 > > On Wed, Feb 19, 2020 at 1:52 PM Neil Madden > 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 insi= de > 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 preferre= d > 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 broa= d > scopes. For service-to-service API calls you typically get an access toke= n > with a single scope that is effectively =E2=80=9Call of GCP=E2=80=9D and = everything is > managed at the level of permissions on the RO service account itself. The= y > only break down fine-grained scopes when you are dealing with user data a= nd > will be getting an access token approved by a real user (through a normal > auth code flow). > > =E2=80=94 Neil > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt > wrote: > > Can you explain more in detail why the client credentials grant type isn= =E2=80=99t > 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=E2=80=99ve seen is for service acc= ounts - > where you essentially want something like client_credentials but for > whatever reason you need the RO to be a service user rather than an OAuth= 2 > client (typically so that some lower layer of the system can still perfor= m > 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=E2=80=99m not convinced this resulted in a material increase= in > security for the added complexity. > > =E2=80=94 Neil > > On 18 Feb 2020, at 21:57, Hans Zandbelt > wrote: > > I would also seriously look at the original motivation behind ROPC: I kno= w > it has been deployed and is used in quite a lot of places but I have neve= r > actually come across a use case where it is used for migration purposes a= nd > the migration is actually executed (I know that is statistically not a ve= ry > 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 i= s > 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. > > =E2=80=94 Justin > > On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 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 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 t= o > allow applications that had been provided password to migrate. Even with > the caveats in OAuth 2.0, implementors decide they want to prompt the use= r > to enter their credentials, the anti-pattern OAuth was created to elimina= te. > > > 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 > > > _______________________________________________ > 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 > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.. If you have > received this communication in error, please notify the sender immediatel= y > by e-mail and delete the message and any file attachments from your > computer. Thank you._______________________________________________ > 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 --00000000000008ead6059fc919e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
2) write an OAuth = 2.1 extension for service account grants. (the grant type could continue to= be "password", but now clearly in the context of a service accou= nt in a different document)

IMHO - if such= a thing gets defined, it should be a separate document. Keep 2.1 as simple= as possible.

=E2=80=94=E2=80=94= =E2=80=94
Dominick Baier

On 28.= February 2020 at 22:04:10, Dick Hardt (dick.hardt@gmail.com) wrote:

It looks lik= e there is consensus to remove ROPC for a user -- but that the password gra= nt is not a bad practice for service accounts. That leads to providing clar= ity on service accounts.

1) add service account gr= ant to the OAuth 2.1 document

2) write an OAuth 2.= 1 extension for service account grants. (the grant type could continue to b= e "password", but now clearly in the context of a service account= in a different document)

With the goal of OAuth 2= .1 being a capture of all the best practices, (2) makes more sense as it co= uld discuss all aspects of service accounts including mapping a client to a= service account.=C2=A0

What do others think?


3D""=E1=90=A7

=
On Tue, Fe= b 25, 2020 at 6:17 AM Nat Sakimura <sakimura@gmail.com> wrote:
Let us do it then and deprecate ROPC.=C2=A0
There definitely are use-cases that need this pattern aro= und me as well, but we are using JWT bearer grant instead. Standardizing th= e behavior is good. I am fine with new service_account grant type as well, = btw.=C2=A0

Nat
2020=E5=B9=B42=E6=9C=8825=E6=97=A5 20:41 = +0900=E3=80=81Neil Madden <neil.madden@forgerock.com> =E3=81=AE=E3=83=A1=E3= =83=BC=E3=83=AB:
I=E2=80=99d be open to defining a new service_= account grant type and removing/deprecating the ROPC grant. I=E2=80=99d als= o be happy if we just said that service account flows should use the JWT be= arer grant, and we document the best practices around that and encourage cl= ient libs to implement support for it.

Should there be a dedicated draft for best practices for service-to-service= usage?

=E2=80=94 Neil

On 25 Feb 2020, at 00:13, Aaron Parecki <aaron@parecki.com&= gt; wrote:

I think we might be going about this discussion the wrong way.

On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=3D40pingidentity.c= om@dmarc.ietf.org> wrote:
Concur with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.madden@forgerock.com> wrote= :
I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be doing=E2=80=9D unless we have concrete security or intero= perability reasons for doing so.

I 100% agree that the job of a standard is not to tell people "what th= ey ought to be doing". Instead, a standard is more about documenting t= he current state of the art as deployed in existing implementations.

With that in mind, I think that leaves us with two concrete problems with t= he password grant:

1) The actual problem with the password grant is end users entering passwor= ds in applications, which the group (mostly) agrees on
2) People are re-appropriating the password grant for things like service a= ccounts or backends that are inflexible, not actually using it for end user= credentials

So it seems like there's actually something missing from OAuth which is= leading people to find the password grant and use that because it's th= e only thing that most closely fits their existing model. It seems like we&= #39;d be better off defining a new extension that captures the use case peo= ple are actually doing, instead of encouraging the continuing use of the pa= ssword grant for this purpose.

----
Aaron Parecki
aaronparecki.com<= br> @aaronpk



On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=3D40pingidentity.c= om@dmarc.ietf.org> wrote:
Concur with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.madden@forgerock.com> wrote= :
I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be doing=E2=80=9D unless we have concrete security or intero= perability reasons for doing so.

I also don=E2=80=99t agree that people doing this are doing anything wrong.= I don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve = learnt over the years not to second-guess their reasons for doing it.

Are Google wrong for using the JWT bearer grant (not client credentials) an= d service accounts? They even go so far as to say =E2=80=9Cscopes are not a= security mechanism=E2=80=9D [1] and tell people to use service account rol= es instead. (Precisely because they also support non-OAuth auth methods, wh= ich bypass any scopes).

Are we really going to tell them to rewrite it all to use the client creden= tials grant?

[1]: https://cloud.google.com/compute/docs/= access/service-accounts#accesscopesiam

On 21 Feb 2020, at 21:04, Justin Richer <jricher@mit.edu> = wrote:

+1. I=E2=80=99ve seen this anti-pattern deployed all over the place, and it= =E2=80=99s time to get rid of it and send people toward what they really ou= ght to be doing.

Another thing I=E2=80=99ve seen is using different service accounts to get = different sets of access for one client =E2=80=94 if you=E2=80=99re doing t= hat, you=E2=80=99ve got a client pretending to do two different things, or = your APIs should be using scopes to differentiate access instead of client/= user identity.

=E2=80=94 Justin

On Feb 21, 2020, at 3:28 PM, Richard Backman, An= nabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

The client IDs can still be opaque identifiers provided by the AS, they jus= t happen to be associated with specific service accounts. Or they could be = the opaque IDs that the AS already issued for the service account. Either w= ay, the AS could issue a token with the appropriate subject and other claim= s for the service account.

If your client identity is bound to a specific service account identity (i.= e., the resource owner), then ROPC reduces down to Client Credentials. What= 's the point in passing two identifiers and two credentials for the sam= e identity?

=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.= amazon.com/identity/


=EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" &l= t;oauth-bounces= @ietf.org on behalf of neil.madden@forgerock.com> wrote:

Sorry, I missed that message.

While this may be a solution in specific circumstances, I don=E2=80=99t thi= nk it=E2=80=99s a general solution. e.g. an AS may not allow manually choos= ing the client_id to avoid things like http= s://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 or may return different introspection results for client credentials toke= ns (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds e= ven more steps for somebody to migrate from existing ROPC usage.

This is asking people to make fundamental changes to their identity archite= cture rather than simply switching to a new grant type..

=E2=80=94 Neil

On 21 Feb 2020, at 14:34, Torsten Lodderstedt &l= t;torsten@lodd= erstedt.net> wrote:

I see - we have gone full cycle :-)

Annabelle=E2=80=99s proposal would solve that. Relate a client id to a serv= ice account and obtain the token data from there.

On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@for= gerock.com> wrote:

Yes, that is great. But mTLS doesn=E2=80=99t support service accounts (!=3D= clients). Maybe it should? Should there be a mTLS *grant type*?

=E2=80=94 Neil

On 21 Feb 2020, at 14:20, Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Have you ever tried the client credentials grant with mTLS? After reading y= our 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 Authenticat= ion

Works very well for us.

On 21. Feb 2020, at 15:12, Neil Madden <neil.madden@forg= erock.com> wrote:

No failures, but it is a much more complex grant type to set up, when you c= onsider 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 t= he AS impose non-standard requirements? e.g. RFC 7523 says that the JWT MUS= T contain a =E2=80=9Csub=E2=80=9D claim, but Google only allows this to be = present if your client is doing impersonation of an end-user (which require= s additional permissions).
* do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, plain O= Auth ones might not) If I do, can I reuse the JWT or must it be freshly sig= ned 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 (=E2=80=98ere be dragons)
* figure out how to distribute the private key to my service

Compared to =E2=80=9Ccreate a service account and POST the username and pas= sword to the token endpoint=E2=80=9D it adds a little friction. (It also ad= ds a lot of advantages, but it is undeniably more complex).

=E2=80=94 Neil


On 21 Feb 2020, at 13:41, Matthew De Haast <= ;matt=3D40co= il.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 w= ouldn=E2=80=99t be having this conversation. So perhaps removing it is an i= ncentive to make that happen.

Neil could you elaborate more on this please. What failures are you current= ly experiencing/seeing with the JWT Bearer grant?

Matt

On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <neil.madden@forgerock.com> wrot= e:
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 w= ouldn=E2=80=99t be having this conversation. So perhaps removing it is an i= ncentive 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 doin= g to follow what is in 6749?
=E1=90=A7

On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <neil.madden@forgerock..com&= gt; wrote:
OAuth2 clients are often private to the AS - they live in a database that o= nly 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, p= ermissions 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 appropriat= e permissions determined. A service account can be created inside such a sy= stem as if it was a regular user, managed through the normal account provis= ioning tools, assigned permissions, roles, etc.

Another reason is that sometimes OAuth is just one authentication option ou= t of many, and so permissions assigned to service accounts are preferred ov= er 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 deplo= yed clients.

See e.g. Google cloud platform (GCP): https://deve= lopers.google.com/identity/protocols/OAuth2ServiceAccount
They use the JWT bearer grant type for service account authentication and a= ssign permissions to those service accounts and typically have very broad s= copes. For service-to-service API calls you typically get an access token w= ith a single scope that is effectively =E2=80=9Call of GCP=E2=80=9D and eve= rything is managed at the level of permissions on the RO service account it= self. They only break down fine-grained scopes when you are dealing with us= er data and will be getting an access token approved by a real user (throug= h a normal auth code flow).

=E2=80=94 Neil

On 19 Feb 2020, at 21:35, Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Can you explain more in detail why the client credentials grant type isn=E2= =80=99t applicable for the kind of use cases you mentioned?

Am 19.02.2020 um 22:03 schrieb Neil Madden <<= a href=3D"mailto:neil.madden@forgerock.com" target=3D"_blank">neil.madden@f= orgerock.com>:

I very much agree with this with regards to real users.

The one legitimate use-case for ROPC I=E2=80=99ve seen is for service accou= nts - 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 bi= t 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 t= o two screens of code. For service to service API calls within a datacenter= I=E2=80=99m not convinced this resulted in a material increase in security= for the added complexity.

=E2=80=94 Neil

On 18 Feb 2020, at 21:57, Hans Zandbelt <hans.zandbelt@z= martzone.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 ver= y 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 w= ay out to stick to an anti-pattern and still claim to do OAuth 2.0. It is p= lain 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 per= iod 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 O= Auth 2.0. People using OAuth 2..1 will do OAuth 2.1.

=E2=80=94 Justin

On Feb 18, 2020, at 3:54 PM, Anthony Nadalin &= lt;tonynad=3D40microsoft.com@dmarc.ietf.org> wrote:

I would suggest a SHOULD NOT instead of MUST, there are still sites using t= his and a grace period should be provided before a MUST is pushed out as th= ere 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<= br> 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 Aaro= n, 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 th= e 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.<= br>

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
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com<= br> @aaronpk

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--
hans.zandbe= lt@zmartzone.eu
ZmartZone IAM - www.z= martzone.eu
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf..org/m= ailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your computer. = Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://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.iet= f.org/mailman/listinfo/oauth
--00000000000008ead6059fc919e7--