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