Manage Mosaic applications

Mosaic applications and clients can be managed either using Management APIs, or from the Admin Portal (as described below).

The Applications page presents a list of all your Mosaic applications, including basic details like its ID and name, when it was created, which admin created it, and the last time a user logged in. You can search for a specific Mosaic application by name using the search box on the top-right, and click to view the Mosaic application settings.

When you open a Mosaic application, you can view its associated clients and configure settings shared across those clients, such as Authentication methods, Advanced settings, Access Control, and B2B Settings when relevant.

You can manage your Mosaic applications from the Applications page:

• Create a Mosaic application by clicking Create Application (see Create Mosaic applications), then configure its settings.
• Edit an app by clicking and then Edit.
• Delete an app by clicking and then Delete.

Each Mosaic application row includes basic information such as:

• Application ID: Identifier automatically generated when the application is created. It cannot be edited.
• Application name: Name of the application, displayed in the Admin Portal.
• Application description: Short description of the application, displayed in the Admin Portal.
• Application logo: The application's logo when needed (e.g., in email templates) in jpeg, png, or webp format.

You can access your Mosaic application settings from the Applications page by clicking its row in the table. Depending on your setup, the details page can include the following tabs:

• Clients
• Authentication methods
• Advanced settings
• Access control
• B2B settings

This tab contains the clients that request Mosaic services for the Mosaic application, such as your retail website, mobile app, backend, or third-party service.

To build identity experiences with Mosaic, you need at least one client in the Mosaic application. You can add multiple clients and support a multi-client setup. Depending on your needs, Mosaic lets you create User authentication clients for OIDC, SAML, or backend-based authentication, as well as Service clients for Fraud Prevention, Identity Verification, and machine-to-machine (M2M) use cases. See Manage clients.

The tab also lists the Mosaic application's SSO client groups, which journey-orchestrated clients select in their Login Experience. See Configure SSO.

Use this tab to configure which authenticators the Mosaic application supports and how they behave. This includes method-specific settings such as password policy, OTP expiration, passkey relying-party settings, social provider credentials, and the branding used by email-based authentication methods.

For step-by-step guidance, see Customize login methods. For hosted-login flow layout, branding, and language, see Manage your hosted login experience and Brand your hosted login experience.

Advanced app settings include:

• Application domain: Configure the application's unique domain. You can use either an Application sub domain generated under the Mosaic domain suffix, or an Application custom domain that uses a domain you own. This domain is used as the app-specific issuer for tokens and related OIDC endpoints. Custom domains require additional provisioning with Transmit Security. For more, see Manage token signing keys and Configure custom domains.

• Public sign-up: Allows non-federated login flows to automatically create new users (or associate existing users with the Mosaic application) the first time they log in. When enabled, auto-creation can be requested via the create_new_user parameter of Authentication APIs, or the createNewUser parameter of the OIDC authorization API. When disabled, these requests return 403 public_signup_disabled.

  Public sign-up and B2B

  Public sign-up doesn't apply to SSO provisioning. Members of an organization configured for SAML or OIDC SSO are created on their first successful login through the organization's identity provider, even when this setting is disabled.

• Token signing keys: Control how tokens issued by this application are signed. You can keep using the tenant-level Global signing key, add a system-generated app-specific key, or upload your own key using BYOK. App-specific signing keys require a unique Mosaic application domain. For more, see Manage token signing keys.

• Device limits: Configure how many registered Web and Mobile devices each user can have in the app. You can set a maximum for each device type and enable auto deletion when the limit is reached and the user registers a new device. Use Delete device-bound authenticators to choose whether automatic cleanup also deletes the removed device's bound authenticators and device keys, or only unlinks its authenticators without deleting them or the device keys. For details on device lifecycle and cleanup, see Device management. For runtime device operations, see the Devices API reference.

• Authentication Hub: Mark this Mosaic application as the tenant's centralized login hub by selecting Set as authentication hub, and configuring the Authentication hub URL. Other applications in the tenant can delegate sign-in to it. Only one can be set as the Authentication Hub for a tenant. See Create an Authentication Hub.

• Service providers: Attach external SAML service providers that should rely on this Mosaic application for SSO, with Mosaic acting as the SAML identity provider. See Federate SSO with Mosaic SAML IDP.

This tab defines who may access the application. It contains Scopes, Permissions, User roles, and Role groups.

A scope says the client may call an operation. A permission says the user may perform the action. Your API checks both. Create scopes and permissions here, then reference the permissions from user roles and assign scopes to clients.

For how Mosaic decides which of these values appear on an access token, see How authorization works.

Use this subtab to define the application's custom scopes. You cannot create a custom scope that uses a reserved OAuth or OIDC scope.

Set the scope value and an optional description. Scope values are case-sensitive and unique in the application. For which scopes Mosaic grants on a token, see How authorization works.

Assign the scopes a client may request with the Update client API. Set allowed_scopes to those scope values. The Admin Portal does not assign custom scopes yet.

Use this subtab to define the application's permissions.

Set the permission value and an optional description. Permission values are unique in the application. User roles reference these values.

Use this subtab to define the application-level user roles your product recognizes, such as booking_agent or finance_admin. Create a role and select permissions from the inventory.

In B2B scenarios, roles are typically grouped into role groups and assigned to organizations. For more about B2B role settings, see Define app roles and Create app role groups.

For B2B Applications only, it contains the app-level settings used for organization onboarding and member access. It includes:

• Settings for the member invitation flow, such as the redirect URI, inviting client, and invite-link lifetime.
• Settings for the Organization admin portal offered to organizations so their admins can manage members and access.
• Settings for refresh token invalidation triggers, that determine which member lifecycle events invalidate refresh tokens and force re-authentication in the B2B context.

For full field-level configuration details, see Configure B2B settings.