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
