It does not make sense to use OAuth in most single party situations. These single-party OAuth use cases are frequently a complete misuse of the framework. I +1 the language “3rd party” in an effort to steer implementors in the right direction.
-- Jim Manico @Manicode > On Aug 28, 2020, at 5:07 AM, Torsten Lodderstedt > <torsten=40lodderstedt....@dmarc.ietf.org> wrote: > > >> On 28. Aug 2020, at 16:56, Dick Hardt <dick.ha...@gmail.com> wrote: >> >> Well, OAuth is not very useful in a monolithic application. No need for an >> interoperable protocol for that kind of application. > > I don’t know why we need to make any assumptions about the application that > uses OAuth. A lot of assumptions might turn out to be wrong. So if me make > assumptions they must be relevant for the protocol design. > > So again, why is “independent” or “third-party” relevant for the protocol > design? > >> >> And in separating functions, you are creating separate trust domains. Yes, >> it is still all internal, but it enables a separation of concerns. >> ᐧ >> >> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt >> <tors...@lodderstedt.net> wrote: >> In my experience OAuth is used in 1st party scenarios as means to separate >> functions (e.g. central user management vs. different products) within the >> same trust domain thus enabling architectural flexibility. >> >> I would just remove any constraint on the kind of applications OAuth can be >> used for. I don’t see how this governs the protocol design. >> >>>> On 28. Aug 2020, at 15:29, Dick Hardt <dick.ha...@gmail.com> wrote: >>> >>> The driver in my opinion for first-party use of OAuth is to separate the >>> trust domains so that the application is scoped in what it can do vs an >>> application that has full access to all resources. I agree that third-party >>> can indicate that internal use does not apply. How about the following? >>> >>> The OAuth 2.1 authorization framework enables an independent >>> application to obtain limited access to an HTTP service, either on >>> behalf of a resource owner by orchestrating an approval interaction >>> between the resource owner and the HTTP service, or by allowing the >>> application to obtain access on its own behalf. This >>> specification replaces and obsoletes the OAuth 2.0 Authorization >>> Framework described in RFC 6749. >>> ᐧ >>> >>>> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt >>>> <torsten=40lodderstedt....@dmarc.ietf.org> wrote: >>> I agree. OAuth works for 3rd as well as 1st parties as well. >>> >>>> On 28. Aug 2020, at 05:26, Dima Postnikov <d...@postnikov.net> wrote: >>>> >>>> Hi, >>>> >>>> Can "third-party" term be removed from the specification? >>>> >>>> The standard and associated best practices apply to other applications >>>> that act on behalf of a resource owner, too (internal, "first-party" and >>>> etc). >>>> >>>> Regards, >>>> >>>> Dima >>>> >>>> The OAuth 2.1 authorization framework enables a third-party >>>> >>>> application to obtain limited access to an HTTP service, either on >>>> behalf of a resource owner by orchestrating an approval interaction >>>> between the resource owner and the HTTP service, or by allowing the >>>> third-party application to obtain access on its own behalf. This >>>> specification replaces and obsoletes the OAuth 2.0 Authorization >>>> Framework described in >>>> RFC 6749. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
