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
