Here we have some node services and a react frontend, all at different urls, each one configured as a client secured with kc in the same domain, and all of them independently work as expected (so, hooray in the first place!).
Now the frontend (auth by keycloak-js) has the ability to embed some of the other services (auth by keycloak-connect express middleware) in an iframe. Unfortunately, these embedded services will redirect their iframe to the login page, requiring the user to log in once more. We would very much prefer if we could use some SSO workflow to not bug the user with too many logins.
At the moment these services reside at service.product.url, next to frontend.product.url and keycloak.product.url, so just changing the path of the KC cookies might be enough, but this will not necessarily stay true in the future.
Also some services will be provided by third parties that don’t share our authentication; in that case multiple logins is not an issue for us, but we mustn’t break the option to still support such third party services.
Can you think of an elegant solution?
On the technical side, we have full control of the frontend server, too.
And, btw, tnx for giving us keycloak, and keep on the great work 
I believe Hostname SPI might help you here.
Hello Sebastian and thanks for your reply. I’m not sure I understand how to make use of it, though. Could you please help me understanding?
I think you refer to using a fixed hostname provider. Would you suggest setting that fixed hostname to the service-url, the frontend-url or the keycloak-url?
Why will this help me to perform SSO in the iframe? When I open the iFrame at frontend.product.url to service.product.url (or open a new browser tab to service.product.url while logged in), there is just a plain HTTP request arriving at the service’s server, without any session or identity information. Does KC not need any information to identify the user that is trying to connect so it can check if that user has already signed in to an active session? SSO works when both server are accessed via localhost on different ports, so I think you are right about the hostname issue, I’d just like to understand why it works.
The problem we had, was not that keycloak was accessible under different names. (I think SPI solves that problems) We were not aware that it’s not enough to only proxy the auth request in our frontend. This way we got all session cookies we need for one client, but they were not added to the auth request from another client. The solution was to remove our proxy route so that we get all sso cookies for our original keycloak domain.