That sounds like a good addition to a separate document Phil. ᐧ On Sun, Mar 1, 2020 at 8:33 AM Phillip Hunt <phil.h...@independentid.com> wrote:
> Why not just require service accounts to use mutually acceptable http > method of authentication? Eg instead id/password, service acnt client > could use mtls auth or http basic or some other method. > > AFAIK this is already widely done. > > Is there so much interop value that specifying only the weakest form of > authentication is warranted? > > Phil > > On Mar 1, 2020, at 4:09 AM, Dominick Baier <dba...@leastprivilege.com> > wrote: > > > 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. > > ——— > Dominick Baier > > On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@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? > > > ᐧ > > On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura <sakim...@gmail.com> 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年2月25日 20:41 +0900、Neil Madden <neil..mad...@forgerock.com> のメール: >> >> I’d be open to defining a new service_account grant type and >> removing/deprecating the ROPC grant. I’d also be happy if we just said that >> service account flows should use the JWT bearer grant, and we document the >> 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? >> >> — Neil >> >> On 25 Feb 2020, at 00:13, Aaron Parecki <aa...@parecki.com> 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= >> 40pingidentity....@dmarc.ietf.org> wrote: >> Concur with the sentiment expressed by Neil here. >> >> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.mad...@forgerock.com> >> wrote: >> I’m not really sure the WG should be telling people what they “ought to >> be doing” unless we have concrete security or interoperability reasons 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 <bcampbell= >> 40pingidentity....@dmarc.ietf.org> wrote: >> Concur with the sentiment expressed by Neil here. >> >> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.mad...@forgerock.com> >> wrote: >> I’m not really sure the WG should be telling people what they “ought to >> be doing” unless we have concrete security or interoperability reasons for >> doing so. >> >> I also don’t agree that people doing this are doing anything wrong. I >> don’t always agree with what our customers do, but I’ve 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) >> and service accounts? They even go so far as to say “scopes are not a >> security mechanism” [1] and tell people to use service account roles >> instead. (Precisely because they also support non-OAuth auth methods, which >> 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#accesscopesiam >> >> On 21 Feb 2020, at 21:04, Justin Richer <jric...@mit.edu> wrote: >> >> +1. I’ve seen this anti-pattern deployed all over the place, and it’s >> time to get rid of it and send people toward what they really ought to be >> doing. >> >> Another thing I’ve seen is using different service accounts to get >> different sets of access for one client — if you’re doing that, you’ve got >> a client pretending to do two different things, or your APIs should be >> using scopes to differentiate access instead of client/user identity. >> >> — Justin >> >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle <richanna= >> 40amazon....@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 could >> 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? >> >> – >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >> >> >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" < >> oauth-boun...@ietf.org on behalf of neil.mad...@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 <tors...@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.mad...@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 <tors...@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.mad...@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....@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.mad...@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.ha...@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.mad...@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 <tors...@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.mad...@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.zandb...@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 <aa...@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 <jric...@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....@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-boun...@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.zandb...@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 >> privileged 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 >> immediately 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 > > _______________________________________________ > 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
