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
