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
