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

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. 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