Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

[David Waite <[e-mail]>]

Multiple concepts often get tacked onto a particular term, which both aids and hinders communication.

From RFC 6749, a public client is defined as:
     "Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.”

RFC 6749 also defines a user-agent-based application:
   " A user-agent-based application is a public client in which the
      client code is downloaded from a web server and executes within a
      user-agent (e.g., web browser) on the device used by the resource
      owner.  Protocol data and credentials are easily accessible (and
      often visible) to the resource owner.  Since such applications
      reside within the user-agent, they can make seamless use of the
      user-agent capabilities when requesting authorization.”

These have over time been conflated. So when people speak of public clients, they may mean a client which has some subset of the following aspects:
- A client which is also a user agent (I personally consider native applications to also be a user agent, but that’s neither here nor there)
- A client that cannot keep a secret and thus cannot be issued a secret
- A lack of guarantee that the client represents a particular agent (that it is unmodified 1st or 3rd party code)
- A client that cannot keep access tokens and traffic confidential (even if that is from a creative resource owner)

The ability to keep a secret is perhaps the least meaningful part of this list. The secret serves a purpose to identify the client, and thus “know” access tokens are being requested by that client. It isn’t that public clients cannot hold a secret that matters - it is that they cannot be reliably identified or assumed authentic.

In the confidential client case, the client is expected to represent particular business goals and possibly a particular organizational relationship. The access token is confidential, the communication with the resources is confidential - driven by business logic which is meant to be fixed to represent those business goals.

In a public client, the security model can try to defend against malicious third parties like web attackers and malicious parties acting as other clients, authorization servers, or protected resources - but you can’t defend against a compromised platform or a sufficiently motivated end user. 

Since a hybrid sharing of tokens between the two is not defined by any specification, we can only assume things like:
- either the backend gives the front-end an access token, another token which acts equivalent to the access token, or sets a cookie value which when applied to resources acts equivalent to an access token
- this means while the backend can keep a secret, it is meaningless in that the access token rights gained from that secret are not confidential
- since the frontend initiates the protocol traffic and has this new credential, the protocol data and which actions are performed are not secured

Now if this backend exposes its own reduced resource server and its own tokens, then this is different - but then I would argue either that:
- conceptually the backend is now the new AS and resource server for my frontend, which is still a public client (but perhaps no longer a public client in the eyes of the original AS)
- or that this is no longer OAuth

-DW

> On Apr 2, 2019, at 9:52 AM, George Fletcher <[e-mail]> wrote:
> 
> Hi,
> 
> In section 6.2 the following statement is made...
> 
>    In this scenario, the backend component may be a confidential client
>    which is issued its own client secret.  Despite this, there are still
>    some ways in which this application is effectively a public client,
>    as the end result is the application's code is still running in the
>    browser and visible to the user.
> 
> I'm curious as to how this model is different from many existing resource server deployments acting as confidential clients. While the application code is running in the browser, only the access token is exposed to the browser as is the case for many RS deployments where the RS returns the access token to the browser after the authorization flow completes. My interpretation of "confidential client" does not include whether the client's code is "visible" to externals or not, but rather whether the client can protect the secret.
> 
> In that sense I don't believe this deployment model is "effectively a public client". A hybrid model description is fine, and I don't disagree that some authorization servers may want to treat these clients in a different way.
> 
> Thanks,
> George