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

[Stian Thorgersen]

+1

On Mon, 14 Oct 2019 at 17:05, Bruno Oliveira <bruno at abstractj.org> wrote:

> So in summary we have an agreement that we should close that PR for
> now and have a proper design document to cover scenarios like SPA+REST
> with Gatekeeper. Does it make sense?
>
> On Fri, Oct 11, 2019 at 2:40 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> > 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
>
>
>
> --
> - abstractj
>