Based on my analysis, I found that the cookie ‘OAuth_Token_Request_State’ for first application is overridden by the second application during the keycloak redirect request after login. This seems to be because both applications share the same domain name.
To confirm this, I just configured the redirect urls of one application as localhost and other one as 127.0.0.1. With this different domain configurations I was able to login without any issues.
Please advice on this.
While this might not exactly solve your issue I can provide some details on the use of that state cookie.
The OIDCKeycloakFilter will generate a state value when the auth challenge is initiated (this is the step that returns a 302 redirect to send the browser to the Keycloak server. This sets a matching value on a cookie called OAuth_Token_Request_State. Once Keycloak authenticates the user, it will redirect back to the call originator and pass that state value as a querystring value. The Keycloak filter compares the querystring value to the cookie value and verifies that they match. One of the benefits of this is a stateless CSRF check, which being stateless is what’s causing your issue since both browser instance are using the same domain of localhost. This is by design to add security and not a bug. You can see the code if you look at the OAuthRequestAuthenticator class on Keycloak’s GitHub project.
If you have access to the KeycoakDeploymentContext object you can change the cookie name (for example in Java) by calling deploment.setStateCookieName("my_cookie_name") when you initialize your filter.
You can also add a new domain to your /etc/hosts file for local development or run something like dnsmasq to use domains other than localhost and avoid that issue.
I hope that helps point you in the right direction.