This page covers the SSO configuration: the client groups, the OIDC and SAML clients they hold, and the SSO journeys that run for them.
SSO is now a feature of Mosaic applications rather than a separate service. Applications can enable SSO by assigning clients to SSO client groups. Existing SSO Service settings were migrated without affecting users, credentials, or sessions, and SSO groups are now called SSO client groups.
SSO applies to groups of clients that share the same login page and the same session policy.
To create an SSO Client Group, go to Applications > your app > Clients tab > SSO client groups, and click + Add SSO client group.
- SSO client group name (required): Identifies the group in the Admin Portal and in the APIs.
- Description: Free text that tells this group apart from the others.
- Login screens (required): Where the login page is hosted. Select Hosted by Transmit Security to use the Mosaic-hosted SSO experience, or Self managed (Custom UI) to use a page hosted on your side.
- Login page URL: Address of the group's login page. It applies to this group only.
- With Self managed (Custom UI), it's required: enter the address of the login page you host.
- With Hosted by Transmit Security, Mosaic generates the URL for the group, and the field isn't shown. The Mosaic application's custom domain doesn't change this URL.
- Session timeout (required): How long a user session stays valid before the user has to authenticate again. Default: 14 days, up to 1 year. See Session timeout. This is the browser SSO session shared by the group's clients. It's separate from each client's Session expiration, which limits how long that client can renew its tokens without a new login; see OIDC advanced settings.
Passkeys use a single Relying Party ID (domain) per Mosaic application, set in Authentication methods > Passkeys. Passkeys work only for SSO client groups whose login page is on that domain or one of its subdomains. If the SSO client groups of a Mosaic application have login pages on different domains, passkeys work only on the groups that match the Relying Party ID.
When the first SSO client group with Hosted by Transmit Security is created, if the Relying Party ID isn't set yet, Mosaic sets it to the domain of the Mosaic-hosted login page. The value appears prefilled in Authentication methods > Passkeys and can be changed. Passkeys then work on every SSO client group whose login page is on that domain.
When the group uses Hosted by Transmit Security, the appearance of those screens, including their default and supported languages, is set with styles — see Manage styling for the Mosaic-hosted SSO experience. With Self managed (Custom UI) the login page is yours, and Mosaic doesn't style it. To localize the content of the journey itself, see Localize journeys.
Each client group can include clients using either OIDC or SAML protocols. Create them in Applications > your app > Clients tab > Clients, and select the group in the client's own settings, under Login Experience. A client therefore joins a group after the group exists: either create the group first from SSO client groups, or create it inline while adding the client.
For the client creation steps and settings, see Configure OIDC clients or Configure SAML clients. In Login Experience, choose Journey-orchestrated, then select the group and the client's SSO journey. For Mosaic-hosted screens, also select a style or use the default Mosaic style. Clients in the same group can use different journeys and styles.
To integrate your application, see Launch OIDC SSO with the Mosaic-hosted experience or Launch SAML SSO with the Mosaic-hosted experience. For screens you host, see Launch SSO with a self-hosted login experience.
Groups can also be managed via APIs.
For API-only backend integrations, create a Service client from Applications > your app > Clients. It works independently of an SSO journey. See Configure service clients.
OIDC clients configured for Journey-orchestrated login also include a Client roles step. Assign roles there as described in Manage client roles. API authorization depends on the client access token and the permissions required by the endpoint; selecting an SSO client group does not replace role configuration. SAML clients have no Client roles step.
SSO journeys authenticate users with the application's own authentication methods.
An SSO journey can use:
- Passkeys
- Passwords
- Email magic links
- One-time passcodes
- Push notifications, configured through the Apple and Google push connector
- TOTP
Configure them in Admin Portal > Applications > your app > Authentication methods tab — see Customize login methods for the settings available for each method.
Note that Face authentication and PIN codes can be configured for the application, but aren't available in SSO journeys.
In SSO journeys, when a user requests to authenticate to an app within an SSO client group, the first step is to verify if a user session is active (using the SSO session validity step). The session timeout defines how long a user session remains valid before re-authentication is required. This ensures the journey takes appropriate actions based on the session’s status.
If the session is still valid, the journey can proceed with specific actions tailored to your business logic.
For example, you might display a redirection message and automatically authenticate the user without requiring their credentials, or if using MFA, only require their username for a lighter login experience. If the session has expired, the user will be prompted to re-authenticate by entering their credentials.
SSO leverages the flexibility of Journeys: each client runs the SSO journey selected on it. Clients that should share a login page and a browser session belong to the same SSO client group, and clients in the same group can run different journeys.
SSO journeys (journeys of "SSO journey" type) have additional features compared to client SDK journeys and are the only journeys compatible with SSO. To learn more about the native logic of SSO journeys, see our dedicated SSO journey overview. For an example of an SSO journey, see our SSO tutorial.
To create an SSO journey, go to the B2C or B2B Identity section (based on your setup), select Journeys, and click Add blank journey. Then, choose the SSO-Journey type. Once the journey is created, select it on each client that runs it: in the client's Login Experience, choose Journey-orchestrated, then pick the journey under Journey.
In B2B, an SSO journey can also invite and onboard new members. That journey is set on the application rather than on an SSO client group, and runs when the member opens the link in the invitation email — see Configure the invite flow.