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