Skip to content

Share user accounts across apps with separate logins

Follow the steps below to configure this scenario. The linked guides provide additional field descriptions and implementation details.

Real-life example: Acme Media has two business units: a news service and a streaming service. Subscribers use one Acme Media account for both, but each business unit keeps its own login and session. The streaming service uses its own sign-in form and authenticates users through Mosaic APIs.

Use case: two or more apps for the same users. Users use the same account and credentials across apps, but sign in to each app separately.

Resulting structure: one Mosaic application containing all clients and one user authentication client per app integration. Journey-orchestrated clients each use a separate SSO client group. Backend-based clients don't use an SSO client group.

Example: one Acme Media Mosaic application shares users and credentials across two business units. The news service client uses journey-orchestrated login with its own SSO client group. The streaming service client uses backend-based authentication without an SSO client group, so the two business units don't share sessions.

Not this use case?

See Choose a setup for your use case to compare all setups.

Before you start

Choose how each app signs users in: journey-orchestrated login through an OIDC or SAML redirect, or backend-based login. See Choose your login experience.

Step 1: Create the Mosaic application

In the Admin Portal, go to Applications and create one Mosaic application for all the apps. See Create Mosaic applications.

All clients in the Mosaic application share its user pool, credentials, and authentication policies. Sharing users doesn't share sessions: session sharing is set by SSO client groups. See Plan your integration structure.

Configure the authentication methods your users will use in the Mosaic application’s Authentication methods tab. For the settings and prerequisites of each method, follow Customize login methods.

Step 2: Prepare the SSO client groups and login journeys

Skip this step for apps that use backend-based login. The Mosaic application gives users one account across all apps, while separate SSO client groups keep their browser sessions separate: create one group for each app with journey-orchestrated login. Placing two apps in the same group would share the login between them.

  1. Create the SSO client groups. In Applications > Application > Clients > SSO client groups, select + Add SSO client group for each app, and configure:

    • SSO client group name: a name that identifies the group.
    • Login screens: Hosted by Transmit Security for Mosaic-hosted pages, or Self managed (Custom UI) for a page you host.
    • Login page URL: for self-managed screens, the address of the page you host. For hosted screens, Mosaic generates the URL; to show users a URL on your own domain, enter a custom login page URL. See Configure custom domains.
    • Session timeout: how long the group's session stays valid. Default: 14 days, up to 1 year.

    Save the group. See Configure SSO.

  2. Create the SSO journey. In B2C or B2B Identity > Journeys, select Add blank journey and choose SSO-Journey. Build the login flow with the authentication methods configured in Step 1, then save the journey. You can also reuse an existing SSO journey. Apps in different groups can use the same journey. The Journeys section of Configure SSO explains where SSO journeys are created and how clients select them.

For a step-by-step example using Mosaic-hosted screens and email OTP, follow Create an SSO journey with the Mosaic-hosted experience. Adapt the journey by adding or replacing steps to match your authentication methods and login requirements.

Step 3: Add the clients

In Applications > Application > Clients, select + Add client and choose User authentication client. Add one client per app integration. For each client, complete the wizard in the tab that matches its type.

  1. General: enter the client name and description.
  2. Authentication flow: leave Does your login use OIDC or SAML authentication? enabled, select OIDC and Client type Web app, and enter the web app's Redirect URIs.
  3. Login Experience: select Journey-orchestrated, the app's own SSO client group, and the SSO journey from Step 2. For Mosaic-hosted screens, select a Style or use the default Mosaic style. See Manage styling for the Mosaic-hosted SSO experience.
  4. Advanced settings: choose the client authentication method and review token lifetimes. See OIDC advanced settings.
  5. Client roles: select the roles the client needs to call Mosaic APIs. If you don't select a role, the client implicitly receives the App Admin role. See Manage client roles.

Save the client. Mosaic generates the client ID and the credentials for the selected authentication method; they're available from the client details page. For all fields, see Configure an OIDC client.

Don't select the same SSO client group on clients of different apps.

Step 4: Integrate each app

Integrate each app with its own client, using the tab that matches its type.

Send an authorization request with the client ID and redirect URI, exchange the returned code for user tokens from your backend, and validate the tokens before creating the app's local session. See Launch OIDC SSO with the Mosaic-hosted experience and Validate tokens.

If an SSO client group uses Self managed (Custom UI), build the login page with the Mosaic Platform SDK, which runs the SSO journey, and host it at the group's Login page URL. See Build your SSO page.

Keep login sessions separate: don't add silent authentication across these apps. Implement session renewal and logout independently for each app. For browser SSO, end the app's SSO session with SSO session logout; for backend-based login, follow Manage backend sessions.

Check the result

To test login, use a user who belongs to this Mosaic application. Create one from Users > + Add Users, enter an email address, and select this Mosaic application. See Manage users. A login method based on email OTP can sign this user in; for passwords or passkeys, the user must register the credential first.

  1. Sign in to the first app.
  2. Open the second app in the same browser. The user is asked to sign in again.
  3. Sign in with the same credentials. The user is authenticated with the same account.