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 <dba...@leastprivilege.com> wrote: > > Yes it would. > > ——— > Dominick > > On 23. July 2019 at 10:08:43, Filip Skokan (panva...@gmail.com > <mailto:panva...@gmail.com>) wrote: > >> Wouldn’t that contradict the security topics BCP? >> >> Odesláno z iPhonu >> >> 23. 7. 2019 v 9:44, Neil Madden <neil.mad...@forgerock.com >> <mailto: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 >>> <mailto: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 >>>> <mailto: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 >>>>> >>>>> <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 >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
