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

[Neil Madden <[e-mail]>]

Not sure I follow - the current OAuth security topics BCP allows for using either state or PKCE for detecting CSRF (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.7.1 <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.7.1>), with some caveats for when state is preferred.

I think I prefer the current wording in the browser-based draft, which provides a much clearer unambiguous recommendation.

-- Neil

> On 23 Jul 2019, at 09:31, Dominick Baier <[e-mail]> wrote:
> 
> Yes it would.
> 
> ———
> Dominick
> 
> On 23. July 2019 at 10:08:43, Filip Skokan ([e-mail] <mailto:[e-mail]>) wrote:
> 
>> Wouldn’t that contradict the security topics BCP?
>> 
>> Odesláno z iPhonu
>> 
>> 23. 7. 2019 v 9:44, Neil Madden <[e-mail] <mailto:[e-mail]>>:
>> 
>>> 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 <[e-mail] <mailto:[e-mail]>> 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 ([e-mail] <mailto:[e-mail]>) 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 <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/ <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
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>