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:
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 <gffle...@aol.com
<mailto: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
--
----
Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
