Hi 

Is their any ETA for this fix? Until the mobile apps are fixed we are unable to authenticate with them through IOS devices such as iPhones since the application doesn't report the device management. We are not able to add an exception for this either as it would remove the requirement for managed devices which drastically increases risk especially with token/session hijack attacks.

We have just moved to Cloud and our Executive team uses Notify Me extensively for approvals so not having this available is a step backwards from their perspective.

Thanks

would love to see a fix for this and not just in some future major release. This really needs to be applied to previous supported release versions in a service update, its crazy how SSO is handled in IFS MWO when connecting to an external IDP for SSO.

The MWO mobile app is using some old archaic internal version of edge it seems with no ability to send information to the IDP, and even a user chooses the 3 dots to launch edge for the SSO to take place (only available in IOS and android...not windows)  there seems to be a lack of information sent to the IDP to determine compliant device information….you don't see this behavior in cloud, just on the mobile side? 

Also please employ SAML as an option for SSO configuration in addition to Open ID Connect for external SSO providers.

• IFS Cloud Web using browser: When you access the IFS Cloud web application directly using the Chrome browser (or Edge), you are using a full, system-level browser instance. This browser can access the cookies and session information of your existing Identity Provider (IdP) session (e.g., if you are already signed into the configured IDP). Therefore, you get a true, seamless Single Sign-On (SSO) experience where you typically aren't prompted for credentials again.
• IFS MWO App: The mobile app uses an embedded web view that is isolated from the system browser. It cannot access the external browser's session data. For security reasons, the app starts a new, secure, internal session, which is why you must re-enter your credentials for the IdP login page within the app's embedded window. 

So the key difference is that the web client in Chrome uses the full browser's shared session, while the MWO app's embedded view uses an isolated, independent session that cannot leverage existing logins from your primary browser application."

different behaviors observed on different devices 

Why the experience differs:

• Windows/Edge: Your successful sign-in likely leveraged deep, operating-system-level integration with Microsoft Entra ID (Azure AD), which allows both the full Edge browser and the app's embedded view to use the same underlying OS authentication token.
• Android/Chrome: Android's security model keeps app data, including web view sessions, sandboxed (isolated) from other apps and the system browser's session cookies. Without specific extra configurations (like using a "broker" app or Chrome Custom Tabs), the user must enter their credentials again in the MWO app's embedded window. 

options to fix 

Option 1: Using a Broker Application - The mobile app must be built using the Microsoft Authentication Library (MSAL) and be configured to use the broker.

option 2: Using browser Custom Tabs - 

This method uses a system browser (like Chrome or another browser supporting Custom Tabs) as the authentication surface instead of a standard embedded web view. 

Steps to configure SSO using Custom Tabs:

App Integration: The app must be developed or configured to explicitly use the system browser for authentication requests.

How to Implement These Configurations

For the MWO app specifically, the ability to support these configurations is dependent on IFS.

• IFS must enable the feature: IFS must build and release a version of the MWO app that is specifically configured to integrate with Microsoft's MSAL and the Android broker or to use Chrome Custom Tabs. As an enterprise-grade app, it's very likely that IFS would choose to integrate with MSAL and the broker, as this also supports other Enterprise Mobility Management (EMM) policies from Intune.
• Customer configuration: Once IFS provides the broker-enabled app, your company's IT administrators will need to perform the backend configuration in the Microsoft Entra admin center. This includes registering the MWO app and potentially setting up Conditional Access policies.
• User action: End-users would then need to install the Microsoft Authenticator app on their devices to facilitate the brokered authentication

if R&D actually reads these pages….. could these be options to fix?