We have the controversy of picking a proper security flow and the suggestion of Resource Owner Password flow was presented. In IEFT draft it's said that one must not use it, while Auth0's docs states that it's not recommended in general but feasible if the encouraged flows aren't available.
The resource owner password credentials grant MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client.
Though we do not recommend it, highly-trusted applications can use the Resource Owner Password Flow ..., which requests that users provide credentials ...
While it's obvious there's no much love for the ROP flow, there's still quite some middle ground between absolutely must not and should under a condition. And if Auth Code Exchange flow isn't possible (as in our scenario), there's still the need to pick something.
In our case, the team decided to skip ROP flow and use Client Credentials flow motivating it as a more secure alternative. I don't get how it is so, since the client now will expose all the goodies based on its ID and secret, while in ROP flow, one needs to also send username and password.
- Is Resource Owner Password flow absolutely not to be used?
- Is Client Credentials flow actually more secure and if so how?
CodePudding user response：
The Resource Owner Password Credentials (ROPC) flow is deprecated - basically from the start - because it defeats one of the primary purposes of OAuth 2, which is to not disclose the end user credentials to the Client. The draft you are referring to is slated to be incorporated in to OAuth 2.1, a revision of the spec that will make it a MUST NOT based on the experience of over a decade of OAuth 2.0 deployment.
The rationale: if you really want to embed direct username/password authentication in an application, there's no reason to use OAuth 2.x. Just use basic authorization, LDAP or some other existing way of presenting a username/password from an application to a backend. The OAuth working group recognises in hindsight that incorporating ROPC in to OAuth 2 was a mistake because it defeats the purpose of OAuth , creates confusion and doesn't offer any benefit over existing alternatives, hence the MUST NOT in the revision.
The Client Credentials (CC) flow addresses a inherently different use case of OAuth 2.0 that does not deal with Resource Owners or end users. If somehow the CC flow is used to implement the ROPC use case, that's a serious abuse of the protocol and its intention leading to the same problems as with ROPC.