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

[Dominick Baier <[e-mail]>]

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 <https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#section-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
<https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#ref-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