Configure B2B application settings

This page is the detail for Setup overview — Step 2: Configure B2B settings.

Configure the B2B application settings to activate the invite flow, expose the Organization admin portal to org admins, and define how refresh tokens are invalidated based on member events.

In Admin Portal, go to Applications > your app > B2B settings tab.

Configure the addresses for redirecting users after completing the invite flow.

• Application URI for inviting members
  The URL in your app where users are redirected when they accept a membership invite — for example, https://your-app.example.com/login. The URL must be reachable by the invited user. Mosaic appends an authorization code to this URL, which your backend exchanges for tokens — see Exchange the invite code for tokens.

• Client for inviting members
  The client that carries the invite. Only clients with PKCE disabled can be selected.

  Select an existing client, or + Add client at the bottom of the list to create one without leaving this tab. See Configure app & client for B2B.

• B2B invite journey
  The orchestration journey invoked when an invited member clicks the email magic link sent to them. The journey runs on the SSO page and receives the org context from the link, so it can onboard the member into the organization they were invited to.

  Select an existing journey, or + Create new journey at the bottom of the list. Give it a Name, set Journey's context to B2B, and select Apply. Mosaic creates an empty journey and selects it here; you build its steps afterwards in the journey editor.

  None, the default, leaves the field unset and the settings still save. Invitations are still sent: the member follows the link and completes Mosaic's ready-to-use onboarding experience, built from the authentication methods configured for the application — see Manage your hosted login experience. Select a journey when you need something the ready-to-use experience doesn't do, such as collecting extra details or driving how the member registers their methods.

  You give the journey its steps later, in Build the B2B journeys.

• Member invite link expiration in minutes Set how long invite links remain valid after they are sent. Adjust to match your onboarding policy.

  • Accepted range: 5–10080 minutes (up to 7 days).
  • Default: 2880 minutes (48 hours).

• Org admin portal domain
  The URL org admins use to reach the Org admin portal.

  This field is read-only. It takes its prefix from the application's Application sub domain and serves it under .org. instead of .app.: an application whose sub domain is yourcompany.app.<environment-suffix> gets yourcompany.org.<environment-suffix>. Set the sub domain in Applications > your app > Advanced settings > Application domain — see Manage applications. Until it's set, this field stays empty.

  Use the copy button to share the URL with the organization's admins.

• Refresh token invalidation triggers Select which member events invalidate that member's refresh tokens.

  • Member suspension: Invalidates refresh tokens when the member is suspended, preventing the session from being renewed.
  • Member password reset: Invalidates refresh tokens when the member's password is reset, preventing sessions authenticated with the previous password from being renewed.
  • Member role update: Invalidates refresh tokens when the member's roles change, so updated roles take effect after the current access token expires and the member authenticates again.

  All three are enabled by default. Invalidating a refresh token doesn't immediately end an active session. The current access token remains valid until it expires, but it can't be renewed. The member must then authenticate again.

Configure how members sign in and which authentication methods they register. Organizations inherit the application's settings as they are.

In Mosaic authentication methods, Password, Email OTP, and SMS OTP are listed by default. Passkey and TOTP appear here once they're configured for the application: select Manage authentication methods at the bottom of the list, or go to Applications > your app > Authentication methods tab. For step-by-step configuration, see Customize login methods.

• Require MFA
  Enable this option to require a second factor after sign-in. When enabled, at least one method must have MFA Experience set to Shown.

  At sign-in, the second-factor prompt shows only the methods that are both Shown here and already registered and active for that member, minus the one they used for the first factor. Two consequences to plan for: a member who signs in with a passkey isn't asked for a second factor, since the passkey satisfies MFA on its own; and a member who has registered none of the methods you allow for MFA can't sign in at all, because one factor isn't enough. Set the Enrollment Requirement of your MFA methods accordingly.

• Sign-in Experience
  For each method, choose how it appears on the login form:

  • Shown: offered as an alternative to the primary method.
  • Primary: presented by default.
  • Hidden: not offered at sign-in. It can still be used for MFA if MFA Experience is Shown.

• MFA Experience
  For each method, choose whether it is available as a second factor when Require MFA is enabled:

  • Shown: available for MFA.
  • Hidden: not available for MFA.

• Enrollment Requirement
  For each method, set the registration requirement applied when members are asked to register their authentication methods during onboarding:

  • Shown - Required: members must register the method before continuing.
  • Shown - Optional: members are offered registration and can skip it.
  • Hidden: members aren't asked to register the method.

  The method set as Primary under Sign-in Experience is the exception: its Enrollment Requirement is fixed at Shown - Required and the dropdown is disabled. Members have to have registered the method they're offered by default. Make another method Primary and the restriction moves with it.

• Enable federated access
  In Federated access, turn on this option to make federated sign-in available to the organizations on this application. It is off by default.

  This setting controls what an organization can choose. With it on, Federated access becomes selectable on the organization's Authentication methods tab, where the organization configures its own Identity Provider (IdP). With it off, that option isn't selectable and every organization on the application signs in with the application's methods.

  Federated access replaces the application's sign-in options for that organization's members. See Configure federated access.

Public sign-up is an application setting for non-federated login flows in which user sign-up is handled directly by Mosaic. When enabled, Mosaic can automatically create a new user the first time they sign in through a direct application login flow. For B2B applications, this setting does not control provisioning through the organization's identity provider: members are still created on their first successful federated login, regardless of the public sign-up setting.

An organization can override this behavior for its own members: Allow sign-up of guest users, in the organization's federated access configuration, takes precedence over the application setting. See Allow sign-up of guest users.

Non-federated login attempts that would create a user when public sign-up is disabled return 403 public_signup_disabled.

For B2B applications that use an invite-only model — where an organization admin adds the member and sends the invitation — disable public sign-up so that self-registration is not available in non-federated flows outside the invite flow. To review or change this setting:

• Per application: open Applications > your app > Advanced settings tab and disable Public sign-up (see Manage applications).
• Per organization: open B2B Identity > Organizations > [your org] > Applications tab > the application > Settings > Authentication methods tab > Federated access, and set Allow sign-up of guest users.