Hi everyone 
,
I am working on a React-based application and using “react”: “^15.4.1”, and “keycloak-js”: “^22.0.3”, for integration. I am trying to enhance the user experience by avoiding full-page redirection during re-login.
Currently, when I call: keycloak.login({ prompt: “login” }) for the re-login,
It redirects the user to the full Keycloak login page, which takes over the entire browser window.
My Goal:
Instead of redirecting the whole app, I want to load the Keycloak login UI inside a custom React dialog (like a modal), so the user doesn’t lose context or feel taken out of the app.
Question:
- Is there a way to embed the Keycloak login page in a modal or dialog component using an iframe or any other mechanism?
- Are there any known limitations (e.g., X-Frame-Options, CSP, etc.) that prevent Keycloak from being embedded like this?
What I Tried:
- Tried loading the login URL in an iframe inside a dialog — but it fails due to browser restrictions.
- Also looked into using
window.open() with a redirect back to the app, but this opens a separate popup (not in the same React dialog).
Any suggestions, best practices, or alternative approaches to achieve this kind of user experience?
Thanks in advance! 
Short answer: no
A bit longer:
OIDC always requires the redirect loops for security reasons ( the user credentials shall never get entered in a context where the client app may have access).
6 Likes
Embedding the login screen is only one part of the problem; Keycloak currently only supports returning the authorization code as part of redirect, which is dictated by OAuth/OIDC, just as @bpedersen2 mentioned.
To pass the code to the “outer” app, you will need to handle the redirect inside your iframe/popup, and then use window.postMessage(). This is non-standard though; there has been an attempt to create an OAuth extension for that, but that’s still an individual draft. Please let me know if you’re interested in this draft and potential implementation in Keycloak.
Exactly!
To add on to this; the OIDC is designed to act as such and it helps prevent phishing attacks too!
Your users will be redirected to their “already known” service (like google login) and only their known selected service should handle the password storing etc etc.
Your keycloak acts as this already known service (unless you further added another identity provider (like google or github, etc.)). The apps/services only trust the identity provider.
1 Like
Dmitry, tbh, IMO having such an approach is nothing else than convenience, it’s nothing about security.
Instead, Keycloak should IMHO focus in an early adoption and implementation of OAuth 2.0 for First-Party Applications [1]. @embesozzi already wrote about this in his blog [2]
jm2c
–
[1] draft-ietf-oauth-first-party-apps-00
[2] Deep Dive into Enhancing User Experience with Native Authentication (OAuth 2.0 for First-Party Apps) and Passkeys in Keycloak | by Martin Besozzi | Medium
3 Likes
