Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

[n-sakimura <[e-mail]>]

Agreed.

On the related issue, issue of exporting the access token that a confidential client got to a public client is there as it was discussed in the Friday’s Oauth WG meeting. Though I did not make any comment on Friday as we were running out of time, I think that is a bad idea as the AuthZ server has issued it assuming that it is kept by a confidential client.

Hybrid response type was made because of the view that the public client should get less privilege.

If we are getting rid of Implicit flow, this aspect need to be addressed.

Having said that: if SPA is using the code flow, is it not acting as a public client without a client secret?

Nat

From: OAuth [mailto:[e-mail]] On Behalf Of Justin Richer
Sent: Thursday, July 25, 2019 8:45 PM
To: David Waite <[e-mail]>
Cc: OAuth WG <[e-mail]>
Subject: Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

This raises an interesting question that I don’t think we’ve addressed yet: how to appropriately vary token lifetimes and access for different clients.

Previously, an AS could see that a client was using the implicit flow and decide to limit token lifetimes or scopes based on that alone. Similarly, I know of at least some AS implementations that let you limit what scopes you allow under the client credentials grant. The key issue is that if all your clients are using the auth code flow (which I agree they should), then how does an AS tell the difference in capabilities between incoming clients?

Obviously it can do it on a per-client basis still, but now an AS is going to have to know a bit more about the app itself. Perhaps we finally need a few more entries in the “application_type” metadata parameter from OIDC’s extension RFC7591 beyond “native” and “web”? But we at least probably want to point out to AS implementors that this is something they want to consider tracking in their data model for clients.

— Justin


On Jul 25, 2019, at 4:04 AM, David Waite <[e-mail]<mailto:[e-mail]>> wrote:





On Jul 24, 2019, at 3:03 PM, Aaron Parecki <[e-mail]<mailto:[e-mail]>> wrote:

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
<[e-mail]<mailto:[e-mail]>> wrote:
<snip>


I would rather say that ANY JS app should use CSP to lock down the browser features to a minimal attack surface. In addition, if refresh or access tokens are involved - further settings like disabling inline scripting (unsafe inline) and eval should be disabled.

I'm not sure what to do with this suggestion. It feels like a blanket
recommendation of enabling CSP will likely be ignored since it's too
broad, and recommending disabling inline scripts is overreaching
unless backed up by a specific threat it's protecting against. Did you
have a particular threat in mind?

I would say that browser applications should take measures to harden their applications again code injection and arbitrary code execution. Examples include eliminating inline script (and limiting embeddable objects as much as possible) via CSP, and versioning third party resources via techniques like subresource integrity.  Mechanisms such as augmenting the codebase to make sure all appropriate user input, data storage, and output properly sanitize data may be used - although they may be more expensive to implement and audit.

The AS should likewise take into account an application’s overall security posture when deciding appropriate policies around delegated authorization scopes and token lifetimes.

Best current practices include turning the screws tightly around CSP. But it is (theoretically) possible to accomplish the same with brute-force sanitization, which has been made simpler with framework support. It is still ultimately the AS job to decide which clients have which capabilities.

-DW
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth