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

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