Learn about SP-initiated SSO for B2B apps

When it comes to identity models, B2B products are in a league of their own. They must navigate the complexities of multi-tenancy while satisfying the demand of enterprise clients for unified employee identity and access management across a plethora of services and applications. Logto has also encountered these demands from customers. In this article, we'll take a product-oriented approach to understanding SP-initiated SSO and how it addresses your customers' needs.

Concept

Let's begin by introducing some key elements you need to understand:

• Service provider (SP): Your applications or services, which could be one or multiple apps sharing a single identity system.
• Enterprise identity provider (IdP): The identity provider your enterprise clients rely on to manage employee identities and application permissions. They might use different providers, such as Okta, Azure AD, Google Workspace, or even custom-built IdPs.
• Service provider’s organization (SP Org): B2B apps often support multi-tenancy for different client organizations.
• Identity provider’s organization (IdP Org): IdPs also support multi-tenancy for different client organizations. Ideally, one enterprise should be able to link its IdP Org to an SP Org, replicating employee identities, but reality can be more complex.
• Enterprise user account: Typically identified by their use of a company email domain for login. This enterprise email account finally belongs to the company.

Then, dive into SSO and two key protocols:

• Single sign-on (SSO): SSO allows users to access multiple services or applications with a single set of credentials. It simplifies access management and enhances security.
• SAML and OIDC protocols: SSO relies on these protocols for authentication and authorization, each with its own advantages and disadvantages.

There are two main SSO triggering mechanisms to consider:

• IdP-initiated SSO: In IdP-initiated SSO, the Identity Provider (IdP) primarily controls the single sign-on process. Users begin the authentication from the IdP's interface.
• SP-initiated SSO: In SP-initiated SSO, the Service Provider (SP) takes the lead in initiating and managing the single sign-on process, often preferred in B2B scenarios.

Now, let's explore SP-initiated SSO in detail.

Surface level: user experience

Unlike B2C products that can offer a couple of fixed social IdP sign-in buttons, B2B products can't dictate which specific Enterprise IdP each customer uses. Therefore, users need to first declare their identity. After confirming they're a member of an enterprise enabled for SSO, they are redirected to their respective Enterprise IdP for login.

To achieve this, you must, on the sign-in page, determine whether the user needs to sign in via SSO and to which IdP they should be redirected. Common methods include:

1. Email domain mapping: Associate an email domain with a specific IdP connector. This affects users with email addresses under that domain. Ensure domain ownership verification to prevent malicious configurations.
2. Organization name mapping: Link an organization's name with an IdP connector, relying on users to remember their organization's name.
3. User personal email mapping: This allows you to directly determine if a user account is enabled for SSO, without relying on Email domains or Org names. You can achieve this by inviting users manually, customizing rules of required SSO, or automatically syncing their accounts through directory synchronization.

In the design of the sign-in homepage, there are typically two forms, which can be chosen based on your product's business:

1. B2B products: Recommend to directly display SSO buttons to make it intuitive for your enterprise client members who need to use SSO.
2. Products compatible with B2C and B2B: Since most users won't use SSO, assess email domains to determine if SSO is required. You can delay presenting credential verification, hiding it initially and revealing it once the user's identity is confirmed.

Underlying complexity: user identity model

However, integrating SSO into your identity system involves much more complexity than simply adding an SSO button to the sign-in page. You need to consider a lot more factors.

Key elements relationships are rarely one-to-one; you need to consider one-to-many and even many-to-many scenarios. To explore these variations gradually:

• One IdP Org with multiple email domains: If you rely on email domains to determine user identity, you must support multiple domain bindings.
• One email domain corresponding to multiple IdP Orgs: If a domain could belong to multiple IdP Orgs, users need to choose the IdP they want for single sign-on.
• One IdP Org linked to multiple SP Orgs: Consider providing the quick capability to connect one IdP to multiple SP Orgs.
• One user account in multiple IdP Orgs and SP Orgs: Different SP Orgs may require verification through different IdPs.

Enabling or disabling SSO within an enterprise can change the way users authenticate, requiring a secure and smooth transition.

• Decision-making for SSO activation: Decisions must be made regarding whether SSO affects only certain tenant SP Orgs or all tenant SP Orgs. The former offers flexibility, while the latter aligns with the trend of enterprise-wide identity and access control.
• Transition period considerations: As an SP, you must accommodate third-party IdP service uncertainties. Enterprise admins always need to access your app by SSO or credentials as an option, and enterprise members might need them during the transition.

These are just some points for addressing various scenarios; many more capabilities and details can be explored.

Conclusion

We hope this analysis of SP-initiated SSO offers you fresh perspectives on enterprise identity solutions. The good news is that Logto is diligently developing solutions that offer simple configuration and out-of-the-box SSO authentication experiences. Stay tuned for our upcoming release, where we'll delve deeper into specific SP-initiated SSO solutions.