Re: [OAUTH-WG] third party applications

[Jeff Craig <[e-mail]>]

OAuth may be overkill for most single-party cases, but there is nothing
about the protocol that precludes the use case. A similar argument could be
made that including the third-party language steers implementers who
perhaps would benefit from OAuth away from the specification, making both
positions low-value arguments. It could make sense to provide a section
discussing this single-party vs third-party issue elsewhere in the document
(or perhaps in a BCP covering application authentication and authorization
that discusses OAuth, but also other options), but I think the Abstract of
this document does not benefit from over classifying the application.

On Fri, Aug 28, 2020 at 11:00 AM Jim Manico <[e-mail]> wrote:

> 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=
> [e-mail]> wrote:
> >
> > 
> >> On 28. Aug 2020, at 16:56, Dick Hardt <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> 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=
> [e-mail]> wrote:
> >>> I agree. OAuth works for 3rd as well as 1st parties as well.
> >>>
> >>>> On 28. Aug 2020, at 05:26, Dima Postnikov <[e-mail]> 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>