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

[Aaron Parecki <[e-mail]>]

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

> I think you are mixing authentication and API access here. Depending on application scenario it makes a lot of sense to use OIDC - but rely on the resulting session to control API access.
> Unless you want to dive into the details here, I suggest you remove the mention of OIDC because it is misleading.

I agree, I removed the mention of OIDC.

> 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?

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
<[e-mail]> wrote:
>
> Hey,
>
> Just read the spec - good to see the progress. Some feedback:
>
> I am yet undecided if I like the categorisation of the “Application Architecture Patterns”. I definitely want to distinguish between applications only accessing same-site back-end services and “others”. Not sure if “dynamic application server" and “static application server” should be handled differently - they are deployment details and should not decide on the application security architecture. Also not sure how realistic it is to deploy a typical applications solely from e.g. a CDN. But I don’t have the right answer wrt to categories right now.
>
> 6.1.  Apps Served from a Common Domain as the Resource Server
>
> > OAuth and OpenID Connect provide very little benefit in this
>    deployment scenario, so it is recommended to reconsider whether you
>    need OAuth or OpenID Connect at all in this case.
>
> I think you are mixing authentication and API access here. Depending on application scenario it makes a lot of sense to use OIDC - but rely on the resulting session to control API access.
> Unless you want to dive into the details here, I suggest you remove the mention of OIDC because it is misleading.
>
>
> 6.2.  Apps Served from a Dynamic Application Server
>
> I have a .NET sample for that
>
> https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore21/BFF
> And a blog post
> https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/
>
> 9.7.  Content-Security Policy
>
>    A browser-based application that wishes to use either long-lived
>    refresh tokens or privileged scopes SHOULD restrict its JavaScript
>    execution to a set of statically hosted scripts via a Content
>    Security Policy ([CSP2]) or similar mechanism.
>
>
>
> 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.
>
> Thanks for doing this work!
>
> ———
> Dominick
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth