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

[Stian Thorgersen]

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 at redhat.com> 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 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
>>
>