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
