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

[Stian Thorgersen]

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 at abstractj.org> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>