Seamless Mobile-to-Web Single Sign-On With The Jou...

With version 3.0, Joule Work mobile app (formerly known as SAP Mobile Start) introduces a feature that many customers have been asking for: seamless Single Sign-On when opening web applications in the in-app browser. In this post I want to explain the problem this feature solves, how it works conceptually, and what administrators need to configure to enable it.

The Problem: Two Sessions, One App Experience

Joule Work mobile app (formerly known as SAP Mobile Start), when connected to SAP Build Work Zone, is the native mobile entry point for the Intelligent Enterprise. From a single app, users can access native features like widgets, push notifications, and smartwatch complications, but also launch web applications directly from the app – for example SAP Fiori apps from SAP S/4HANA, collaborative Workspaces in SAP Build Work Zone, advanced edition, custom extensions build on the SAP Business Technology Platform, and more.

When a user taps on a tile that opens a web application, the Joule Work mobile app instantiates the in-app browser provided by the mobile operating system – iOS or Android. This is a technical context switch: the native application session, which is managed by SAP Mobile Services and backed by SAP Cloud Identity Services – Identity Authentication, is logically separated from the browser sessions of web applications, for example SAP S/4HANA Public Cloud Edition.

As a result, the in-app browser may not have a valid session for the target web application when launched. The user is redirected to the identity provider and prompted to log in again. This is particularly jarring because, from the user's perspective, they are just navigating within their app.

The Previous Recommendation – and Why It Was Not Ideal for all customers

Customers could avoid this by enabling the “Remember me” functionality of SAP Cloud Identity Services – Identity Authentication. This feature creates a long-living session cookie in the browser, keeping users signed in across browser sessions for a configurable duration. A similar capability exists on many corporate identity providers (third-party IdPs) to which SAP Cloud Identity Services – Identity Authentication may be configured delegating the actual authentication. Long-lived cookies on these providers effectively keep the user session alive in the in-app browser in the same manner.

However, this approach has a fundamental drawback: long-lived session cookies are not ideal and may not be wanted to be generically configured on the company's Identity Provider. Furthermore, “Remember me” only prolongs the time until a user is asked to sign-in again in the in-app browser – it is not fully getting rid of it.

Another alternative that some customers consider is password-less sign-in using client certificates. While this is a genuinely secure and, once set up, a convenient approach, it is not feasible for all customers and all users. Client certificates typically require an active Mobile Device Management (MDM) system to push certificates to managed devices – meaning unmanaged devices, common in bring your own device (BYOD) environments, are excluded. Beyond the deployment challenge, mobile operating systems restrict access to the system keychain for third-party apps, so not all in-app browser variants can reliably make use of client certificates. Other password-less options such as FIDO passkeys or biometric-based flows can require some form of manual user interaction during authentication, which breaks the seamless experience users expect when tapping a tile in the app.

The New Solution: Mobile-to-Web SSO

With version 3.0, Joule Work mobile app introduces a dedicated Mobile-to-Web Single Sign-On flow that bridges the native session and the in-app browser – securely, without requiring long-lived cookies. Here is how it works conceptually:

The mobile app already holds a valid session with SAP Cloud Identity Services – Identity Authentication (in the context of SAP Build Work Zone, to which the app is connected to). The SAP Cloud Identity Services tenant generally serves as the trust anchor for both SAP Build Work Zone, the native app and other SAP and non-SAP solutions including web applications exposed to SAP Build Work Zone. This shared trust is what makes it possible to bridge the two worlds: because both the native app session and the target web applications are anchored in the same SAP Cloud Identity Services tenant, it can act as a secure intermediary, translating the native session into a web session in the in-app browser without requiring the user to authenticate again.

When the user opens a web application in the in-app browser, the app first exchanges its active native session for a short-lived, one-time use SSO token issued by SAP Cloud Identity Services. This token is valid for only a very short time and can only be used once by the mobile app for (re-)establishing a session in the in-app browser on the mobile device.

This is done by passing this one-time SSO token to SAP Cloud Identity Services within the browser context. The SAP Cloud Identity Services validates the token, maps it to the user's identity & native session, and establishes a regular web session – setting the standard browser session cookies. From there, the accessed target web application authenticates against SAP Cloud Identity Services – Identity Authentication transparently via its standard SAML or OIDC flow reusing the established IAS session with no user interaction required.

The key properties of this approach:

Security-friendly: The SSO token is a one-time use token with a short validity. There are no long-lived session cookies involved on the identity provider side.
Admin-controlled: The feature can be controlled via a feature flag in SAP Mobile Services Admin Cockpit of the Joule Work mobile app. The administrator also defines exactly which web applications are trusted for this flow by configuring them in SAP Cloud Identity Services – Identity Authentication.
Broadly compatible: The feature works with all in-app browser variants offered by Joule Work mobile app on iOS and Android. It also works with all web applications – SAP solutions as well as custom or third-party apps – as long as they share a common SAP Cloud Identity Services – Identity Authentication tenant with the environment the mobile app is onboarded to.

Key Prerequisite: SAP Cloud Identity Services – Identity Authentication as the Common Trust Anchor

For the Mobile-to-Web SSO flow to work, SAP Cloud Identity Services – Identity Authentication must be the identity provider for both the native mobile application and all web applications that should benefit from seamless SSO. The trust is established and maintained through SAP Cloud Identity Services, making it the single common denominator across all participants.

It is important to clarify that SAP Cloud Identity Services – Identity Authentication does not need to be your end users' primary authentication system. In many enterprise landscapes, SAP Cloud Identity Services acts as an identity proxy, delegating the actual authentication to a corporate identity provider such as Microsoft Entra ID or other identity providers. This is fully supported. The only requirement is that SAP Cloud Identity Services is the first common trust anchor in the chain – meaning all participating web applications are configured to trust it directly, even if it in turn proxies to a corporate IdP.

One configuration detail to be aware of in proxy setups: the “Forward All SSO Requests to Corporate IdP” setting in SAP Cloud Identity Services must not be enabled for the applications involved in the Mobile-to-Web SSO flow. When this setting is active, SAP Cloud Identity Services bypasses its own session handling and always redirects to the corporate IdP – which would cause the Mobile-to-Web SSO token to be ignored, and users would end up with a login prompt again. Beyond Mobile-to-Web SSO, enabling this setting can also cause issues in iFrame-based in-place app integration scenarios, as corporate identity providers frequently block iFraming to protect against clickjacking and similar attack vectors. For more information on this setting, see Forward All SSO Requests to Corporate IdP (SAP Help).

The trust for the Mobile-to-Web SSO flow is configured explicitly in SAP Cloud Identity Services. The administrator defines which web application entries in SAP Cloud Identity Services are allowed to participate in this flow – only applications that have been explicitly added to the trust configuration can benefit from it. In addition, SAP Cloud Identity Services validates the URL of the target web application against the allowed redirect URIs configured for the trusted application. This means a web application can only receive a seamless SSO session if its URL matches one of the permitted redirect URI patterns. Both aspects – the application trust list and the redirect URI validation – ensure that the administrator retains full control over which applications can be reached via this mechanism.

Please note: Customers with SAP Build Work Zone subscriptions created before March 2025 may not yet be using SAP Cloud Identity Services – Identity Authentication directly. For these environments, it is necessary to explicitly switch the authentication mechanism. Subscriptions created after that date are automatically set up with SAP Cloud Identity Services – Identity Authentication. Please refer to the SAP Help documentation for the migration steps: Switching to SAP Cloud Identity Services – Identity Authentication.

Pro tip: As with other features that depend on shared sessions and cookies – such as the iFrame-based in-place integration of web applications – it is important that all components share a common super domain. We strongly recommend operating SAP Cloud Identity Services – Identity Authentication and your SAP cloud solutions under the SAP Common Super Domain cloud.sap. If you are not yet familiar with this topic, our earlier blog post explains the background and the configuration steps in detail: Demystifying the Common Super Domain for SAP Mobile Start.

Which Web Applications Are Covered Automatically?

When Joule Work mobile app is connected to SAP Build Work Zone, both share the same Application entry in SAP Cloud Identity Services – Identity Authentication. This means that SAP Build Work Zone itself is automatically within the trust scope – no additional configuration is needed for it.

This automatic coverage includes for example:

SAP Build Work Zone, advanced edition Workspaces – collaborative workspace content embedded in the Work Zone experience
Custom extensions hosted on SAP BTP – applications built for example with the SAP Cloud Application Programming Model, deployed to the SAP BTP and served using the Approuter of SAP Build Work Zone. (For details on building such extensions, see Building Pro-Code Extensions for SAP Mobile Start)
SAP Fiori apps from SAP S/4HANA On-Premise or SAP S/4HANA Cloud Private Edition running through an SAP Cloud Connector using a Principal Propagation Destination – these are tunneled through the BTP subaccount and are therefore covered by the same Application entry

The key distinction is that automatic coverage applies to applications that are part of – or tunneled through – the SAP BTP subaccount and its corresponding SAP Cloud Identity Services Application. Applications that run on their own infrastructure and have their own independent trust relationship with SAP Cloud Identity Services are not automatically covered, regardless of whether they are launched in embedded (“in-place”) mode or opened directly (“ex-place”). A prominent example is SAP S/4HANA Cloud Public Edition: even when it is iFramed within the SAP Build Work Zone shell, it has its own Application entry in SAP Cloud Identity Services and must be explicitly added to the Native-Web Trust group.

For all such web applications – SAP solutions with their own IAS Application entry, third-party apps, or any app not part of the Work Zone BTP subaccount – administrators add them to the trust configuration in SAP Cloud Identity Services – Identity Authentication as described in the setup steps below.

Administrator Setup

Step 1: Verify That IAS-Based Authentication Is Active

Before enabling the feature, confirm that SAP Build Work Zone is using SAP Cloud Identity Services – Identity Authentication as its identity provider. If this is not yet the case, follow the migration steps referenced in the prerequisite section above.

Step 2: Enable the Feature Flag in SAP Mobile Services

In the SAP Mobile Services Admin Cockpit, navigate to the Client Settings. In the Feature Flags section, locate the entry named “MobiletoWebSingleSign-On” and activate it.

Screenshot showing the highlighted feature flag in the activated state in the Mobile Services Admin Cockpit.

For reference, the corresponding documentation can be found here: Single Sign-On for Web Apps – SAP Help

Step 3: Add Trusted Web Applications in SAP Cloud Identity Services

For web applications that are not automatically covered through the SAP Build Work Zone application (see the previous section), you can add them to the trust configuration:

Sign in to the administration console for SAP Cloud Identity Services.
Go to Applications & Resources → Applications.
Select the application entry that corresponds to your SAP Build Work Zone instance.
Go to the Trust tab, then navigate to Application APIs → Dependencies → Native-Web Trust.
Click Add and select the application with which you want to establish trust.
Save your selection.

Screenshot of SAP Cloud Identity Services to maintain Native-Web Trust Settings

Users opening applications from this trust list in the in-app browser will now benefit from the seamless Mobile-to-Web SSO flow.

Step 4: Verify the Redirect URIs of Trusted Applications

As described in the prerequisite section, SAP Cloud Identity Services validates the URL of the target web application against the allowed redirect URIs of the trusted application entry. For SAP-delivered solutions – such as SAP S/4HANA Cloud Public Edition – the redirect URIs are typically pre-configured correctly by SAP and no further action is needed.

However, for custom-built applications or third-party web apps that rely on the general SAP Business Technology Platform application entry in SAP Cloud Identity Services, you should verify that the application's URL is covered by the configured redirect URI patterns. If the URL does not match any permitted pattern, the Mobile-to-Web SSO flow will not complete successfully for that application.

You can review and adjust the redirect URIs in the SAP Cloud Identity Services administration console under the application's configuration. For the rules and wildcard syntax supported for redirect URIs, refer to the SAP Help documentation: Redirect URIs and Post Logout Redirect URI Rules (SAP Help).

Summary

With the Mobile-to-Web SSO feature, Joule Work mobile app version 3.0 closes the session gap between the native app context and the in-app browser – cleanly, securely, and with full administrator control.

Key takeaways:

The feature eliminates the need for long-lived “Remember me” cookies on the identity provider, which are a security concern and not universally available.
It is based on short-lived, one-time use SSO tokens issued and validated by SAP Cloud Identity Services – Identity Authentication, which acts as the common trust anchor.
The feature is optional and in control by the customer: an administrator (de-/) activates it via a feature flag in SAP Mobile Services Admin Cockpit of Joule Work mobile app and controls which web applications participate via the Native-Web Trust configuration in SAP Cloud Identity Services – Identity Authentication.
SAP Build Work Zone web UIs and tunneled embedded business apps are automatically covered. Additional apps can be added with a few clicks.
The feature is compatible with all in-app browser variants in Joule Work mobile app and all trusted web applications, regardless of whether they are SAP solutions or custom apps.

If you need further assistance configuring and making use of this new feature in the Joule Work mobile app, feel free to contact our product management team using jouleworkmobile@sap.com, which will be able to suggest the next steps for your scenario.