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

From: George Fletcher <[email-masked]>
Date: Tue, 2 Apr 2019 11:52:51 -0400

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

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 2 Apr 2019 08:57:24 -0700

Thanks, this is a good question. I was talking with someone about this
draft the other day and had the same question myself. Re-reading RFC6749,
"public client" does describe only the limitation of the client protecting
its own credentials, so I think you're right that this paragraph is
misleading. However I suspect that some ASs will still want to treat
clients where the access token ends up in the browser differently. Is that
a fair assessment? I think the fix to this paragraph would be a slight
rewording to just remove the mention of public clients.

Aaron

On Tue, Apr 2, 2019 at 8:53 AM George Fletcher <[email-masked]> wrote:

> 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.
>
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: George Fletcher <[email-masked]>
Date: Tue, 2 Apr 2019 12:10:06 -0400

I think it's fair to call it out (either in the paragraph here or in the 
security considerations). The issue is that the security aspect of the 
access token ending up in the browser is probably true in many contexts 
other than SPAs:)

What about something like...

In this scenario, the backend component is likely a confidential client 
which is issued it's own client secret. Note that in this model, the 
access_token obtained by the backend component will be delivered to the 
browser for use by the SPA so is more exposed than in the classic 
confidential client model. Some Authorization Servers may wish to limit 
the capabilities of these clients due to risk considerations.

... or something like that.

On 4/2/19 11:57 AM, Aaron Parecki wrote:
> draft the other day and had the same question myself. Re-reading 
> RFC6749, "public client" does describe only the limitation of the 
> client protecting its own credentials, so I think you're right that 
> this paragraph is misleading. However I suspect that some ASs will 
> still want to treat clients where the access token ends up in the 
> browser differently. Is that a fair assessment? I think the fix to 
> this paragraph would be a slight rewording to just remove the mention 
> of public clients.
>
> Aaron
>
>
> On Tue, Apr 2, 2019 at 8:53 AM George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     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
>
> -- 
> ----
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com>

---

From: Pedro Igor Silva <[email-masked]>
Date: Wed, 3 Apr 2019 09:12:20 -0300

Hi,

I've seem some implementations where the token is not directly delivered to
the browser by the backend, but some temporary UUID that later the SPA can
exchange for an access token.

Do you think this is a good approach to the recommendation you are
discussing?

In addition to that, could you clarify more what would be the limitations
that ASes may wish to impose to these clients?

Regards.
Pedro Igor

On Tue, Apr 2, 2019 at 1:10 PM George Fletcher <gffletch=
[email-masked]> wrote:

> confidential client model. Some Authorization Servers may wish to limit the
> capabilities of these clients due to risk considerations.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 3 Apr 2019 11:36:28 -0400

From a security perspective, I think that using a UUID (or session 
cookie) which allows the SPA to retrieve the access_token is effectively 
the same as the confidential client directly returning the AT to the 
browser. Basically, it's the different between whether the browser has a 
copy of the access_token or not.

As to recommendations the AS might want to take, probably depends on a 
lot of factors. The factor that the browser has access to the 
access_token is just one of many affecting the overall risk to the 
Resource Server and the overall ecosystem. The risk of the browser 
having the access token is that there are more vectors for the token to 
be compromised and if the token is a bearer token then the risk is 
higher that the access token could be replayed by a malicious actor.

So, it's possible the AS might want to limit the ability of actions 
associated with those access tokens based on the risk of the actions 
enabled within the ecosystem by the RS.

I'm not sure there are definite recommendations that can be provided.

On 4/3/19 8:12 AM, Pedro Igor Silva wrote:
> Hi,
>
> I've seem some implementations where the token is not directly 
> delivered to the browser by the backend, but some temporary UUID that 
> later the SPA can exchange for an access token.
>
> In addition to that, could you clarify more what would be the 
> limitations that ASes may wish to impose to these clients?
>
> Regards.
> Pedro Igor
>
> On Tue, Apr 2, 2019 at 1:10 PM George Fletcher 
> <gffletch=[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     I think it's fair to call it out (either in the paragraph here or
>     in the security considerations). The issue is that the security
>     aspect of the access token ending up in the browser is probably
>     true in many contexts other than SPAs:)
>
>     In this scenario, the backend component is likely a confidential
>     client which is issued it's own client secret. Note that in this
>     model, the access_token obtained by the backend component will be
>     delivered to the browser for use by the SPA so is more exposed
>     than in the classic confidential client model. Some Authorization
>     Servers may wish to limit the capabilities of these clients due to
>     risk considerations.
>
>>     Thanks, this is a good question. I was talking with someone about
>>     this draft the other day and had the same question myself.
>>     Re-reading RFC6749, "public client" does describe only the
>>     limitation of the client protecting its own credentials, so I
>>     think you're right that this paragraph is misleading. However I
>>     suspect that some ASs will still want to treat clients where the
>>     access token ends up in the browser differently. Is that a fair
>>     assessment? I think the fix to this paragraph would be a slight
>>         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.
>>
>>         "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
>>
>>     -- 
>>     ----
>>     Aaron Parecki
>     [email-masked] <mailto:[email-masked]>

---

From: David Waite <[email-masked]>
Date: Wed, 3 Apr 2019 22:47:42 -0600

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