> We are not talking about ROPC mandating OAuth2, but about OAuth-2.1 > forbidding the user of ROPC.
Absolutely and this seems like a good thing. ROPC seems very close to a use case that calls for OIDC instead of a OAuth2x token so I endorse the move. -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 12, 2020, at 1:23 PM, Francis Pouatcha <[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 >>>> <[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
