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 <gffle...@aol.com> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
