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. 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
