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

Yes it would.

———
Dominick

On 23. July 2019 at 10:08:43, Filip Skokan (panva.ip@gmail.com) wrote:

Wouldn’t that contradict the security topics BCP?

Odesláno z iPhonu

23. 7. 2019 v 9:44, Neil Madden <neil.madden@forgerock.com>:

Technically it could be optional, but it means that a CSRF attempt will
only be detected by the AS not by the client. If we consider the
possibility of a malicious AS, then this could allow Login CSRF attacks
against the client. The client would also have to be sure that the AS
actually implements PKCE. So I think it’s safer to leave the recommendation
as-is.

On 23 Jul 2019, at 08:28, Dominick Baier <dbaier@leastprivilege.com> wrote:

Forgot one more thing

In 7.1

Browser-based apps MUST use the OAuth 2.0 "state" parameter to
   protect themselves against Cross-Site Request Forgery and
   authorization code swap attacks and MUST use a unique value for each
   authorization request, and MUST verify the returned state in the
   authorization response matches the original state the app created.

Isn’t state optional when PKCE is used?

thanks
———
Dominick

On 22. July 2019 at 08:14:33, Dominick Baier (dbaier@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
<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

_______________________________________________
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