It may be programmatically equiv but from a trust perspective very different.
Usually client cred flows are from trusted entities and fixed endpoints. Phil > On Feb 21, 2020, at 5:05 PM, Richard Backman, Annabelle > <richanna=40amazon....@dmarc.ietf.org> wrote: > > ROPC without a client ID or authentication is functionally equivalent to > Client Credentials grant with client secret authentication in the request > body. You've just renamed "client_id" to "username" and "client_secret" to > "password". > > The AS simply needs to be able to resolve the client ID to the service > account. You could use any of the following strategies, depending on the > environment: > * Use service account identifiers as client IDs > * Use encrypted blobs containing service account identifiers as client IDs, > so someone can't choose a client ID by creating a service account with a > specific identifier > * Use opaque values that the AS can resolve to service account identifiers, > e.g., via a database lookup > > If the AS needs the service account's password because it's authenticating > against a legacy system, then use the service account password as the client > secret. Stack mTLS on top, if you want. If the AS just needs to resolve the > account so it can put it in tokens that RSes will look at, then you can use > whatever client authentication mechanism you want. > > Is there a scenario I'm missing here? > > – > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > > > On 2/21/20, 1:53 PM, "Neil Madden" <neil.mad...@forgerock.com> wrote: > > The AS doesn’t issue the service account IDs, that’s the whole point - > integration with existing systems. Lot’s of people don’t have the luxury of > rebuilding systems from scratch to fit in with the preferences of the OAuth > WG. > > ROPC doesn’t require client authentication, or even a client identifier. > If you’re using a service account you indeed don’t need to bother issuing > client credentials. The same is true when using the JWT bearer grant. If you > want to increase security you can use cert-bound access tokens. > >> On 21 Feb 2020, at 20:28, Richard Backman, Annabelle <richa...@amazon.com> >> 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
