Re: [keycloak-dev] [KEYCLOAK-9127] CSRF support when using credentials in cookies

We also have the following related request: https://issues.jboss.org/browse/KEYCLOAK-11082 This emphasises my point that the SPA+REST same-domain scenario needs to be properly designed, rather than done through random PRs. On Fri, 11 Oct 2019 at 07:38, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > The hybrid SPA+REST secured with Gatekeeper is a scenario that we would like to cover with Gatekeeper. It's a pretty broad scenario though and would need to be properly supported in Gatekeeper. So I would argue that this is a perfect case for asking for a design proposal. > > As a quick idea Gatekeeper would need to know what parts are the SPA and what parts are the REST endpoints. For the SPA app it would need to drive the authorization code flow on the Gatekeeper side, with a confidential client. It would also need to expose some endpoints the SPA can use like /login /userinfo /logout. After the SPA has logged-in a cookie should be set that allows the SPA to invoke the REST endpoints (on the same domain). This would have to have CSRF protection, but maybe not CSRF tokens as you don't want to have to modify the SPA itself. SameSite and CORS will probably be better options here. On the REST side Gatekeeper should be able to use the cookie instead of the bearer token. Further, it should probably work with one Gatekeeper instance securing both SPA+REST as well as separate Gatekeeper for the SPA and REST. > > On Thu, 10 Oct 2019 at 15:50, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: >> >> Some time ago we got this PR for Gatekeeper: >> https://github.com/keycloak/keycloak-gatekeeper/pull/446. But I'm >> 50/50 on this. Even though I think it's great to add extra protection >> to Gatekeeper, we will end up with a new dependency and implementation >> of something that apps could handle. Plus, the inclusion of SameSite >> (https://github.com/keycloak/keycloak-gatekeeper/pull/482) helps to >> mitigate CSRF. >> >> If we take into consideration all the security threats that we have >> today, probably dependencies like https://github.com/unrolled/secure >> should also be included too. >> >> At the moment, I'm leaning toward to reject this change, as I don't >> see any real need for this, but if you have any thoughts, please let >> me know. >> >> -- >> - abstractj >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev