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

I also think it would be useful, but a problem is that things like “application type” are usually a stand in for a whole bunch of different attributes that we actually care about. That’s what happened with web/native and why, to my knowledge, nobody really uses those in lieu of things like public/confidential and redirect URI locations instead for policy decisions. If we do enumerate these, we would also need to enumerate all of the things it means.

I tried to shy away from “application type” style switches in XYZ’s straw man, and instead opt for recipes of applying the different options to different kinds of clients. I don’t know how long that will hold up though.

— Justin

On Jul 25, 2019, at 8:11 AM, Filip Skokan <panva.ip@gmail.com<mailto:panva.ip@gmail.com>> wrote:

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.

I would very much like to see that. native/web possibly in combination with token_endpoint_auth_method and the client being DCR or "static" is far from being enough to make a policy decision.

S pozdravem,
Filip Skokan

On Thu, 25 Jul 2019 at 13:45, Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:
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 <david@alkaline-solutions.com<mailto:david@alkaline-solutions.com>> wrote:

On Jul 24, 2019, at 3:03 PM, Aaron Parecki <aaron@parecki.com<mailto:aaron@parecki.com>> wrote:

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
<dbaier@leastprivilege.com<mailto:dbaier@leastprivilege.com>> 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
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth