12

Recently my application using Keycloak stopped working with a 400 token request after authenticating.

What I found so far is that within the token request, the Keycloak cookies (AUTH_SESSION_ID, KEYCLOAK_IDENTITY, KEYCLOAK_SESSION) are not sent within the request headers causing the request for a token to fail and the application gets a session error.

By digging more, I found that Chrome blocks now cookies without SameSite attribute set, which is the case for the keycloak cookies and that's why they are never parsed within the token acquisition request after authenticating.

The error I get:-

enter image description here https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

https://adzerk.com/blog/chrome-samesite/

This is very serious as it blocks applications secured by Keycloak library to be able to communicate with the keycloak server.

Update: With the new google chrome cookie SameSite attribute, any third party library using cookies without SameSite attribute properly set, the cookie will be ignored. https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

https://www.chromium.org/updates/same-site

Ziko
  • 919
  • 2
  • 10
  • 22
  • 1
    Does this issue resolve things for you? https://issues.redhat.com/browse/KEYCLOAK-12125 – rowan_m Mar 11 '20 at 11:45
  • @rowan_m yes, just found out about this. But I'm relying on red hat version so will need to wait for an update from their end or try a workaround.. – Ziko Mar 11 '20 at 13:26
  • I will leave this post as it might be helpful for people who are going to experience this with the new google chrome update rollout. https://www.chromium.org/updates/same-site – Ziko Mar 11 '20 at 15:13

3 Answers3

8

If you are facing this issue while using keycloak-js adapter.

Then the reason for this issue:

By default, the JavaScript adapter creates a hidden iframe that is used to detect if a Single-Sign Out has occurred. This does not require any network traffic, instead the status is retrieved by looking at a special status cookie.

Workaround (Not a fix):

This feature can be disabled by setting checkLoginIframe: false in the options passed to the init method.

eg.,

keycloak.init({ onLoad: 'login-required', checkLoginIframe: false })

Nagendra Darla
  • 91
  • 1
  • 4
  • 2
    That's correct but note that the iframe usage is very useful for many cases such as detect a logout from a second tab etc unless you extra control your app with websocket calls. You will need to update your keycloak server to fix this issue as they have released a version to support that. – Ziko Aug 26 '20 at 01:33
  • Agree. That is why I mentioned it as workaround. Definitely this has to be fixed in the back end to pass SameSite attribute. – Nagendra Darla Aug 26 '20 at 02:14
  • Looking at the release notes, I think this was addressed in v8.0.2. – Jason Leach Aug 31 '20 at 23:02
1

For those who are looking for a short time solution until they update their libraries.

You can do the following in Chrome:-

  • Go to chrome://flags/
  • Search for "Samesite"
  • Disable "SameSite by default cookies" and "Cookies without SameSite must be secure" flags.
  • Relaunch.
Ziko
  • 919
  • 2
  • 10
  • 22
1

With Chrome 91+ the settings in flags are gone, but accessible with commandline, with 94 these settings are not accessible.

It is possible to use Firefox or Safari meanwhile.

Oleksandr Starov
  • 11
  • 1