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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]>: >>>>>> >>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> 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 >>>>>>>>> <[email protected]> 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 <[email protected]> On Behalf Of Dick Hardt >>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>> To: [email protected] >>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> -- >>>>>>> ---- >>>>>>> Aaron Parecki >>>>>>> aaronparecki.com >>>>>>> @aaronpk >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> [email protected] >>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
