On Tue, May 12, 2020 at 9:50 AM Jim Manico <j...@manicode.com> wrote:
> Forgive me if this question is late or poor context, but wouldn’t OIDC be > a better replacement for ROPC since it’s essentially a authentication flow? > > What use case for ROPC mandates OAuth2 over OIDC? > We are not talking about ROPC mandating OAuth2, but about OAuth-2.1 forbidding the user of ROPC. > -- > Jim Manico > @Manicode > > On May 11, 2020, at 11:00 PM, Francis Pouatcha <fpo= > 40adorsys...@dmarc.ietf.org> wrote: > > > I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password > Credentials) with the following reasoning: > > Auth Code Grant: > There are many use cases on the market where redirection based flows do > not work. As we see in the "OAuth 2.1 - require PKCE?" thread, the > complexity of user agents on non controllable client devices still make > user agent redirection a challenge. > > Client Credentials Grant: > Requires the registration of an oAuth client. > - Citing the iot device use cases Beena which do not have a comfortable > way to have iot devices register with AS. > - This is a registration flow for the oAuth client role and for the RO > (Resource Owner). Remember resource owner credentials might be sourced from > system external to the AS like company's LDAP. oAuth Client Credentials > are generally managed by the AS. > For these reasons, we shall not use Client Credential Grant to manage RO > authorization. > > ROPC: > Having an oAuth Client proxy the auth request of the RO to the AS only > presents a security risk if the oAuth Client is a third party application.. > Therefore, the decision on whether to accept ROPC for a specified client > shall be left to the AS. Discarding this use case will take a lot of > business from oAuth servers back to the old market. > > Beside this, I mentioned in my previous post that there are use cases in > the market where permanent passwords are replaced with one time passwords.. > > A lot of work is also being done in the direction of having the RO send > signed proof of ownership to the AS through the ROPC flow using the > password field. > > Therefore, I am ok with raising the attention of implementers the same > way we are doing with PKCE, mentioning that ROPC must only be used if AS > / oAuth Client can guarantee security of the RO credentials exposed to the > oAuth Client. > > /Francis > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
