App-to-web SSO

App-to-web single sign-on (SSO) allows users to transfer their authenticated session from a mobile application (using the OneWelcome Mobile SDK) to a web browser seamlessly on the same device. This solution is designed to offer a frictionless experience when transitioning from the mobile app to a web browser, because the web application typically offers more extensive functionality.

The common use case for this technology arises when some features are not available in the mobile application, necessitating a transition to the web application. Ensuring that this switch is as smooth as possible is critical to maintaining a positive user experience. The principles of session extension can also be applied to other transitions, such as app-to-app or web-to-app, though the primary focus here is on mobile app-to-web transitions.

This approach plays a key role in offering a seamless and efficient user experience by reducing interruptions typically caused by multiple authentication prompts when switching between platforms.

Supported identity providers

This functionality is available when using a OneWelcome iDAAS core identity provider (IDP):

• Tulip version R103 and later

• CIM version 6.2.0 and later

The supported IDP is responsible for maintaining an allowlist for the target URLs. Target URLs that are not included in the allowlist are rejected.

OneWelcome mobile SDK integration

Using the OneWelcome mobile SDK, developers can specify a target URL that requires authentication. The SDK checks the validity of the mobile app’s session, establishes a session with the IDP, and redirects the user to the specified URL while maintaining their logged-in status.

You can find detailed information for each SDK:

• iOS
• Android
• Flutter
• React Native

How it works

1. The mobile app initiates an app-to-web SSO request. This request returns a URL that contains a one-time token with a limited lifetime.

2. Open this URL in a web browser. It creates an SSO session at the OneWelcome IDP.

3. After the session is created, it's redirected back to the web application.

4. At this point, the web app needs to initiate a (silent) authentication request via a supported SSO protocol, like SAML or OIDC.

5. When receiving an authentication response, the web app might need to exchange an authorization code for tokens (OIDC) or do artifact resolution (SAML).

6. The user is authenticated in the web app and can use all web functions from the browser.

Implementation options

Directing a user to a web application can happen in several ways:

• Embedded web view: To create an experience that is similar to a native mobile experience, use the mobile operating system's support for different types of browsers. Use interceptors to show the webview only after the web app is loaded, and show a spinner when waiting for the webview.

• Native mobile browser: For scenarios where it should be transparent to users that they are going to the web application, you can use a redirect to the native mobile browser. Optionally, you can use a dialog box to inform the user that they are leaving the app.

Simplified flow diagram

Session management

The session created on the web is not linked to the session in the mobile app. The lifecycle of the sessions should therefore be managed independently. In other words, a logout on the web does not log out of the mobile app unless a separate process is implemented for it.

Key benefits

• Seamless user experience when transitioning from the mobile app to the web

• Leveraging existing authentication without requiring users to log in again

• Support for standard SSO protocols (SAML, OIDC)

• Independent session management for enhanced security