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

>
> 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> 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>
> wrote:
>
>
>
>
> On Jul 24, 2019, at 3:03 PM, Aaron Parecki <aaron@parecki.com> wrote:
>
> On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
> <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
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>