Yes it would. ——— Dominick
On 23. July 2019 at 10:08:43, Filip Skokan (panva...@gmail.com) wrote: Wouldn’t that contradict the security topics BCP? Odesláno z iPhonu 23. 7. 2019 v 9:44, Neil Madden <neil.mad...@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 <dba...@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 (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 <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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
