Francis We had a long discussion on this topic earlier this year:
https://mailarchive.ietf.org/arch/msg/oauth/mG6tkmXSOxwakC0184snKCGxfSE/ On Wed, Apr 8, 2020 at 3:25 PM Francis Pouatcha <f...@adorsys.de> wrote: > Hello Aaron, > > Deprecating Resource Owner Password Credentials Flow (Direct Grant) > without replacement might make a strict oAuth 2.1 server (with no backward > compatibility to oAuth2.0) unusable for a good part of "First Party" > applications on the market. These are application environments where the > operator of the AS is the same one deploying the mobile App using Direct > Grant. > > Not sure it is a good idea to limit scope oAuth 2.1 on existing > functionality of oAuth 2.0 unless we are planning an oAuth 3.0 soon. > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ > > On Wed, Apr 8, 2020 at 6:03 PM Aaron Parecki <aa...@parecki.com> wrote: > >> Hi Francis, >> >> The Resource Owner Password Credentials grant is being deprecated in the >> OAuth 2.0 Security BCP: >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.4 >> >> > The resource owner password credentials grant MUST NOT be used. >> >> As this OAuth 2.1 draft is meant to consolidate the best practices across >> the existing OAuth 2.0 documents, and is explicitly not intended to define >> any new behavior that is not already in an adopted document, we can't >> accept your suggestion of adding a new OTP-based grant in this document. >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk <http://twitter.com/aaronpk> >> >> >> >> On Wed, Apr 8, 2020 at 2:59 PM Francis Pouatcha <f...@adorsys.de> wrote: >> >>> As a replacement of RFC 6749 I am missing a "Direct Grant" with the >>> same simplicity as the "Resource Owner Password Credentials" grant of RFC >>> 6749. >>> >>> The reason is that browser redirects are too complex and most of the >>> time badly implemented by small teams. For the sake of having SMEs use >>> oAuth 2.1 with their limited development capacities, I suggest keeping the >>> simple "Resource Owner Password Credentials" with an OTP replacing the >>> permanent password. >>> >>> We also have sample implementations working on the market with OTP based >>> "Resource Owner Password Credentials" with full compatibility to RFC >>> 6749. >>> >>> -- >>> 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
