Subject: [OAUTH-WG] third party applications

From: Dima Postnikov <[email-masked]>
Date: Fri, 28 Aug 2020 13:26:41 +1000

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 <https://tools.ietf.org/html/rfc6749>.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 28 Aug 2020 12:01:49 +0200

I agree. OAuth works for 3rd as well as 1st parties as well. 

> On 28. Aug 2020, at 05:26, Dima Postnikov <[email-masked]> wrote:
> 
> Hi,
> 
> 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
> 
>    Framework described in 
> RFC 6749.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Fri, 28 Aug 2020 06:29:05 -0700

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-masked]> wrote:

> > 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
> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 28 Aug 2020 16:49:41 +0200

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-masked]> 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
> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt <torsten=[email-masked]> wrote:

---

From: Dick Hardt <[email-masked]>
Date: Fri, 28 Aug 2020 07:56:56 -0700

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-masked]>
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.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 28 Aug 2020 17:07:26 +0200

> On 28. Aug 2020, at 16:56, Dick Hardt <[email-masked]> 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 <[email-masked]> wrote:

---

From: Jim Manico <[email-masked]>
Date: Fri, 28 Aug 2020 05:59:52 -1000

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=[email-masked]> wrote:
> 
>

---

From: Jeff Craig <[email-masked]>
Date: Fri, 28 Aug 2020 11:24:18 -0500

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 <[email-masked]> 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
>
>
> >> 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.
> >
> >> And in separating functions, you are creating separate trust domains.
> Yes, it is still all internal, but it enables a separation of concerns.
> >> ᐧ
> >>
> >> 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.
> >>
> >>> 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
> >>>> 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
> >>>>

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 28 Aug 2020 09:36:59 -0700

I agree. While the original motivations for OAuth were to support
third-party apps, it's proven to be useful in many other kinds of
situations as well, even when it's a "first-party" app but the OAuth server
is operated by a different organization than the APIs. I don't think the
abstract needs any qualification on this and would only confuse people
further. Any clarifications of which situations are appropriate for using
OAuth could be explored in a different section in the spec.

Aaron Parecki