It’s difficult to give advise without lot of detailed information. I nevertheless give it a try.
Mechanically, the application would need to use a different grant, credential instead of ROPC. If such an application today already uses a distinct client_id, the AS must be set up to relate this client_id and the service account the same app used before directly. With that the respective deployment is able to leverage all client authentication methods, including mTLS. > On 21. Feb 2020, at 16:02, Neil Madden <neil.mad...@forgerock.com> wrote: > > But we’re talking about existing deployments. Are you suggesting that people > should bulk rename all of their clients to match the service accounts (or > vice-versa)? > > — Neil > >> On 21 Feb 2020, at 14:54, Torsten Lodderstedt <tors...@lodderstedt.net> >> wrote: >> >> >> >>> On 21. Feb 2020, at 15:47, Neil Madden <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. >> >> I don’t see this as a fundamental change, it adds another claim/permission >> source to a client id. >> >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 >> >> This can be solved by either using the id of the service account as sub or >> even put the service identity into a dedicated realm. We implemented the >> later strategy at Deutsche Telekom couple of yrs ago. >> >>> >>> — Neil >>> >>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <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
