> We are not talking about ROPC mandating OAuth2, but about OAuth-2.1 forbidding the user of ROPC.
Keep in mind that while the Security BCP explicitly forbids the use of the Password grant in OAuth 2.0, technically OAuth 2.1 just never includes it in the first place. Subtle difference. Aaron Parecki On Tue, May 12, 2020 at 10:23 AM Francis Pouatcha <fpo= [email protected]> wrote: > > > On Tue, May 12, 2020 at 9:50 AM Jim Manico <[email protected]> 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= >> [email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
