Well, OAuth is not very useful in a monolithic application. No need for an interoperable protocol for that kind of application.
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 <[email protected]> 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 <[email protected]> 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= > [email protected]> wrote: > > I agree. OAuth works for 3rd as well as 1st parties as well. > > > > > On 28. Aug 2020, at 05:26, Dima Postnikov <[email protected]> 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
