We've developed a web app using the Genesys Cloud JavaScript SDK, that uses Token Implicit Grant to authenticate to Genesys Cloud. Authentication is set up to use Microsoft Azure SSO (Entra ID).
The app works fine as a standalone application: When the app's web page is loaded (or refreshed), the app calls "setPersistSettings(true)" then "loginImplicitGrant(...)" to authenticate the user, which results in one of the following occurring:
If the browser's local storage contains an access token that is still valid, it will be used, and no redirection occurs.
Otherwise, the application will navigate to the Genesys Cloud authorisation URL…
2.1) If the user has recently authenticated to Genesys Cloud, then Genesys Cloud will recognise this (from cookies) and will redirect back to the app URL with an access token (i.e. without prompting them to re-enter their credentials).
2.2) Otherwise, Genesys Cloud redirects the user to the Microsoft SSO service (login.microsoft.com) which prompts them for their credentials, etc, and then redirects back to the app URL with an access token.
This works perfectly when the app is running standalone. However when running as an Integration (within an IFRAME in the Genesys Cloud UI), scenario 2.2 above results in either a blank page being displayed, or an error message (depending on browser), which Customer Care have confirmed is due to login.microsoft.com including the header: X-Frame-Options: DENY
Obviously the root cause of the issue is that Microsoft don't allow their SSO service to run within an IFRAME. However the question I'd like to ask is:
Is there any known/recommended mitigation to allow SSO to reliably work for an app that is running as an Integration in Genesys Cloud?
For example: Is there any way that Genesys Cloud can detect that the app is running as an Integration within an authenticated Genesys Cloud UI session and short-circuit the SSO procedure?
Microsoft doesn't allow iframing their login window for security reasons. We cannot bypass critical security features in your local browser to complete an explicitly prohibited workflow. If you need to use SSO, you need to do it in a standalone window.
This process for your app isn't part of Genesys Cloud; it's something your local app would do and is completely dependent on what your local app is and how it works and how you choose to implement this feature. At its core, It's popping a new window for the oauth flow, then your redirect URL page to needs to have a way to communicate with the page that launched the window to give it the auth token, or at least tell it that the flow completed and it should check for a token somewhere (e.g. local storage). You might search your favorite search engine for something like "javascript how to know when popup window closes" if you don't already have an approach in mind; there are multiple ways to accomplish this process.
I was really hoping that you guys would evangelise some best practice code but I've worked it out for anyone who needs some help in future. Note this is a work around, refactor as necessary.
Inside main.js (wrapped around your client.loginImplicitGrant)
var popup = window.open("login.html", "_blank", "width=800,height=700");
var timer = setInterval(function () {
if (popup.closed) {
// initialisation code
clearInterval(timer);
}
}, 500);
Then you need to add exitRedirectUri to your code which is https://<widget iframe url>/exit.html. Then in your oauth authorise that https://<widget iframe url>/exit.html URL as a valid redirect URL.
The way this works is that on the widget initialising, a popup opens, it tries to do an implicit grant which then redirects to Microsoft SSO if required and then once it is successful the window closes.
So I tried turning it on and reproducing the issue, and unfortunately it doesn't seem to have made any difference. No pop-up window appeared, and I ended up with the blank window symptom. (This actually makes me think that there could be two distinct issues: The first being the blank window issue where I don't see any X-Frame-Options header in the response from login.microsoft.com; and the second being the error message displayed in the browser relating to the X-Frame-Options header?)
I can't find that setting documented on the resource center, but if it's not behaving per the description, please open a case with Genesys Cloud Care to investigate.