Linux Firefox + Keycloak 22.0.1 issue(continuation of issue 21307)

[ssill2]

Before reporting an issue

• I have searched existing issues
• I have reproduced the issue with the latest nightly release

Area

authentication

Describe the bug

This is a follow-on to the issue described in #21307

I have a web application that has a react UI that does keycloak authentication against keycloak 21.1.2. It was discovered that the same issue occurs on Firefox(Rocky9) but it seems primarily when the app is deployed on docker and the authentication is done against our staging instance of keycloak. However, this morning my boss had the same issue using Safari while talking to the staging version of our application. That application is deployed using k8s.

It was suggested in #21307 that 22.0.x fixes the issue. I deployed 22.0.1 to see if this in fact fixes it.
While it now gets to the app's landing page, after about 5 seconds it get booted back to before the login screen. My app presents a page with a "Login" button it it. click this triggers the whole auth process and afterwards sends it to the app's landing page.

On Chromium(linux) this doesn't happen, and on Edge(windows) this doesn't happen either.

I have a java (wildfly + vaadin ) application that uses wildfly's oidc client and works fine and has the whole time. The problem seems to be centered around the react app.

Version

22.0.1

Expected behavior

The app being authenticated using keycloak should log in as normal.

Actual behavior

The app landing page is pulled up but after about 5 seconds or so it's kicked out.

How to Reproduce?

This seems to be particular this one react application, and only with this Firefox on linux and Safari

I thought maybe it was because the app still had keycloak-js 19.0.1 dependency it's package.json. I cleared out node_modules and changed this dep to be 22.0.1 to agree with latest keycloak release. no change.

Anything else?

everything worked fine in this configuration before update to 21.x + of keycloak, 20.0.x worked great.

[ssill2]

This is a fully patched Rocky 9 host. The version of the firefox rpm is 102.14.0-2.el9_2

[ssill2]

what's frustrating is I can bring up the same app deployed locally in FF and Chromium side by side. Chromium works just fine, but FF, after about 5 seconds, kicks back to the screen with the login button after having displayed the same landing page that chrome stays on.

[jonkoops]

This is a fully patched Rocky 9 host. The version of the firefox rpm is 102.14.0-2.el9_2

@ssill2 is this still reproducible in the latest version of Firefox for you?

[ssill2]

I'm using the firefox that comes with rocky 9, and is updated via yum. Give me a few minutes and I'll spin up the application again and verify again. it did this as recently as yesterday.

[ssill2]

I just did a "yum update --refresh" and there were no updates. so that firefox package is the latest available for rocky 9.

I just verified the behavior is the same. visit url, Simple page with a "login" button is displayed. Clicking this gives the keycloak login form. Entering credentials and hitting enter takes me to my app's landing page. Then after 5 seconds, I'm booted back to the page with "login" button, even though I have a valid keycloak session. and I know it's valid because if I open my other java + vaadin app that uses the same realm, I'm taken directly in because of SSO.

When the page is redirected back to my "login" page I see this in javascript console

[jonkoops]

Aside from what is available on Rocky Linux, the latest version of Firefox is 116, is the problem reproducible there as well?

[ssill2]

let me see if I can test from the windows side, or get a newer firefox on the linux side. I don't have a good way to test if the safari issue my boss was having is addressed with 22.0.1 as well without deploying 22.0.1 to our staging keycloak. one thing at a time though.

[ssill2]

I'm pulling 117 from mozilla directly, so let's see how that works.

[ssill2]

ok, so that fails too, but more messages in javascript console

I'm starting to think this could because in my dev environment I'm not using TLS for my app or keycloak.

[ssill2]

my java + wildfly + vaadin app that also uses keycloak for auth(using oidc-client in wildfly) works just fine regardless

[ssill2]

if this is a dev only problem because of lack of TLS, I'm less concerned since that's not how it's configured in staging and prod for us since it's in GCP behind an ingress that gets a real cert and ip address/hostname

[jonkoops]

@ssill2 I have this repo I use for testing locally with fake TLS, perhaps it might help reproduce it?

[ssill2]

let me dig into this on tuesday after the long weekend. Thanks

[ssill2]

ok, I think your repo recreates the issue. I followed the instructions exactly. I did have to edit the line in my /etc/hosts file that mapped localhost and localhost.localdomain to ::1 since it was getting a connection refused.
A quick run of netstat showed me that 5173 was only listening on v6

I just edited this line in my /etc/hosts
::1 localhost localdomain localhost6 localhost6.localdomain6
to be
::1 localhost6 localhost6.localdomain6

Once I did this I reran the steps on latest FF 117 and things all came up.

In your playground app I hit login and it says user is logged in and then after 5 seoncs it says the user isn't authenticated. Exactly what I'm seeing in my app, but in my case when the user isn't authenticated it sends them back to login page.
Here's a screenshot

[jonkoops]

I am actually able to reproduce this in the aforementioned test project. This seems like a pretty critical one, so I am marking this for the next patch release (we might even want to do a release just for this fix).

[ssill2]

that's great news! Thanks!

[ssill2]

I'll be interested to see if this also fixes safari. I don't have a mac to try your test project on though.

[edewit]

So it's the update token, looking in the console it seems it results in a status 400 because just before the token is updated the refresh token gets cleared as well

[ssill2]

I'm glad you're able to reproduce it. That's first step in fixing for sure.

[edewit]

Okay we found out what the cause of the problem is, firefox has a strange implementation of requestStorageAccess, because as it needs can only be called from user interaction. We might have to work around this by adding a "firefox" specific check

[jonkoops]

I have a preliminary PR up to fix this issue under #23393. If you are affected by this issue, please test your setup with the changes in that PR and let us know if it fixes the issue.

[ssill2]

I might not be able to get to this today, but I can look into this tomorrow

[ssill2]

@jonkoops do you have an easy way for me to test this using your kjs-playground? I've not tried to build keycloak from source, I've only used it by extending the docker container. If you can point me at the easiest way to test I'll be happy to.

[jonkoops]

@ssill2 I've been testing this by building the Keycloak server from source by running mvn clean install -DskipTests. You can then run the Quarkus server in dev mode by running the following in the quarkus directory:

KEYCLOAK_ADMIN=admin KEYCLOAK_ADMIN_PASSWORD=admin mvn -f server/pom.xml compile quarkus:dev -Dquarkus.args='start-dev --http-port=8180 --proxy=edge'

Then follow all the instructions in the playground repo, but skip the pnpm run server:start command, as the server should already be running.

[ssill2]

Alright, just getting started this morning and working on my first cup of coffee. I'll give this a try. Thanks! I can only test FF however, Someone with a mac will have to test Safari

[ssill2]

Ok building now, I'll let you know!

[ssill2]

build succeeded, going to run keycloak and then your playground proj

[ssill2]

looking good. FF 102 on Rocky 9 works. going to fire up 117 and try it also

[ssill2]

I can confirm that firefox 117 also works!

I'd definitely recommend someone with access to test this with safari give it a whirl too.

Good job! :)

[jonkoops]

Great, thanks for testing this @ssill2!

[ssill2]

Surely! Thanks for fixing! 🥇

[sebastianohall]

Hello! Not sure if this is the correct place, but I am seeing the same exact issue in chrome using the Bitnami helm chart 16.1.5 and keycloak:22.0.3 image on a Kubernetes cluster. I know Bitnami does some stuff on top of the base keycloak image, but I feel like it shouldn't have too much effect on this particular issue. Here are the steps to reproduce:

1. Install Bitnami helm chart 16.1.5 using keycloak:22.0.3 image on a Kubernetes cluster
2. Try to open the admin console in Chrome version 117.0.5938.89 (I have tried different versions also)
3. Note that the admin console does not load (spinner keeps spinning).
4. In the console, see the error: Refused to frame 'http://keycloak.url.redacted/' because it violates the following Content Security Policy directive: "frame-src 'self'". index.js:150

Edit: I should add, this is chrome on Windows.

[ssill2]

Interesting, Chrome/chromium as been the one that has constantly worked for me. Regardless I think the fix hasn't become part of a release yet. I've been watching for a this like a hawk. I don't use the bitnami image, yet, but I agree I've not seen bitnami do anything in their other images like wildfly to think that the behavior should differ from the official keycloak one.

[jonkoops]

The fix for this issue has been backported, it will be included in the 22.0.4 release.

[ssill2]

awesome! thanks for all your work on this! 🥇

[dominiktopp]

Hi, thank you for you work on this. I worked not say that #23393 fixes this issue. It is rather a workaround.
Keycloak.js still uses iframes with sandbox attribute set to 'allow-scripts allow-same-origin'. But the storage access api clearly states, that ‚allow-storage-access-by-user-activation‘ is also needed to have access in sandboxed iframes (see my post #22839 (comment) above)
As far as I understand Firefox does not really have false positives in storage access api, it’s rather the sandbox of the iframes

[jonkoops]

It is rather a workaround.

To be very honest with you it's all a workaround, and all of this will go away in the future, it will just not be possible to place third-party cookies at some point in the future when the removal is rolled out. Best we can do is fallback 'gracefully' to the redirect flow until the Federated Credential Management API becomes a thing.

Even the OpenID specification acknowledges that this is a an issue.

As far as I understand Firefox does not really have false positives in storage access api, it’s rather the sandbox of the iframes

While this could be true in some situations, the MDN documentation clearly states that there are exceptions for either return value. So we have to take it into account nonetheless.

Dealing with a false negative here is much easier as we can fall back to the redirect flow, even if it is a degraded experience. But having a false positive has a much larger fallout, as it needs to be checked in subsequent code.

TLDR; I wanted to have simple code for now so that I can verify this indeed fixed this bug, even if it might be possible to request storage access in Firefox (which we still need to determine), the fallback flow will be good enough to resolve this bug.

Keycloak.js still uses iframes with sandbox attribute set to 'allow-scripts allow-same-origin'. But the storage access api clearly states, that ‚allow-storage-access-by-user-activation‘ is also needed to have access in sandboxed iframes (see my post #22839 (comment) above)

Like I mentioned before, we just wanted to fix this bug now quickly so that it no longer is a critical issue. Now that this has been resolved I will be looking into possible enhancements we can do to improve this. I'll also be testing this and extending the code so that we can see if it is possible to request storage access.

Hopefully explicit user interaction will not be required to make this work as expected, but we'll find out soon enough.

[rkoplinger]

I don't think that #23393 fixes this issue. Without 'allow-storage-access-by-user-activation' there is no access to cookies in sandboxed iframes and session monitoring does not work.

[jonkoops]

@rkoplinger this was already discussed above. We will progressively enhance this in a future PR, but right now this will simply fall back to the redirect flow for Silent Authentication and disable any Session Status checks.

[jonkoops]

Logged the follow-up to this issue under #23872. Please redirect any further discussion about said issue there.