Business To Business To Consumer

Overview

Offer a SaaS software package, where your customers have consumers as customers or users. The end users of the software control their own identity and typically self-register to gain access to your system.

With this case, users typically access your SaaS software using hostnames tied to customers: customerA.example.com and customerB.example.com, or yoursaas.customerA.com or yoursaas.customerB.com.

You can have each customer’s users isolated, so that customer A’s users are distinct from customer B’s users. The users belonging to customer A will be logically isolated and separate from the users of customer B. You can customize the login screens, password rules, allowed login methods (including social login), and security settings for each of your customers. This is common practice when private labeling software.

Or you can allow end users to switch between customers, like a user can do with GitHub organizations. Each user can have different permissions for each customer. This is useful if there are cross cutting users like contractors, who might work with more than one customer account.

Problem

You have an application that you sell to customers; they then have their own users. You want these users to safely log in to your application with a customized experience unique to each customer. You also want to safely store users’ personal identifiable information and credentials, but allow customers to query and manage their users.

Solution

With the b2b2c use case, you allow the users of your customers to securely authenticate. You can also allow your customers to manage users.

This use case is appropriate when the identity of the end user is not controlled by the customer, but rather by the end user themselves. If the identity of the end user is controlled by the customer, the b2b2e use case is a better option.

Prerequisites

You have configured your application or applications to delegate authentication to FusionAuth via the Authorization Code grant and the hosted login pages.

Example Scenario

Suppose your company, ClownPass, sells a ticketing system for circuses. Your software package lets customers buy tickets to see adorable clowns and great feats of strength. Circuses sometimes offer free events, so you need to support both paid and free customers.

Your customers are the circuses, and their users are their customers. Each circus has their own policies about login methods, password length, and more.

You are super excited because you’ve landed both Ringling Bros. and Barnum & Bailey Circus and Cirque du Soleil as customers. They have customers of their own, who may be either individuals or organizations buying tickets. Here’s a diagram of the relationship between ClownPass, its customers and the end users.

The set of customers for each circus can overlap. Jamie Morgan is an example of a customer of both circuses.

Actors/Components

• your customer and their client application (mobile app or browser)
• your customer’s user and their client application (mobile app or browser)
• your application
• FusionAuth

Implementation Steps

There are three implementation steps to ensure your customers’ users will always be able to get the tickets they need. This is a tenant based implementation, where users are stored in different FusionAuth tenants.

The steps include:

• Setting up your system to handle adding new customers
• Letting customers’ users sign in or register
• Allowing your customers to manage their users and other settings

Here’s a high level sequence diagram of the process of adding new customers. Each customer is represented as a tenant.

Adding new customers.

Here’s a high level sequence diagram of a user logging in to one of the customer’s ticketing systems. The application is responsible for mapping the user to the correct customer.

Users logging in.

Here’s a high level sequence diagram of a customer admin managing their users. The admin functions are integrated with the application admin screens using API calls.

Tenant admin management of their users.

Let’s look at these steps in detail.

Adding New Customers

To add new customers, you need to make changes to both the ClownPass ticketing application and FusionAuth configuration.

Preparing The ClownPass Application

Make sure your circus SaaS application can handle multiple tenants. At a minimum, you need to ensure your application has some way to distinguish each customer’s access points. There are a couple of ways to do this, but the most typical is to offer a different hostname for each customer. If the ticketing application is hosted at example.com, you might have the following hostnames:

• ringling.example.com for Ringling Bros. and Barnum & Bailey Circus ticketing
• cirquedesoleil.example.com for Cirque du Soleil ticketing

Ensure your web application can respond to multiple hostnames. If you don’t want to have customer specific hostnames, there are other options.

There are other aspects of a multi-tenant application, such as logically isolating customer data. Such multi-tenant application architecture guidance is beyond the scope of this document.

Configuring FusionAuth

For each new customer, you’ll need to update configuration in the ClownPass FusionAuth instance. You’ll need to:

• create a new Tenant
• create a new Application in that Tenant
• configuring the correct redirect URL for the Application
• create a new Tenant locked API key
• configure the Application to use desired Identity Providers, such as Google Login
• create Email Templates and Themes appropriate for the customer’s brand

You can script these steps using one of the SDKs.

Record information such as the API key, the client Id and client secret from the Application configuration in your application’s database. Later, your application will look up this information based on the request hostname.

When using FusionAuth Cloud, you can configure FusionAuth to respond to different hostnames. You can also do the same with self-hosted FusionAuth. In addition to the hostnames above, you could also have:

• auth.ringling.example.com for Ringling Bros. and Barnum & Bailey Circus login host
• auth.cirquedesoleil.example.com for Cirque du Soleil login host

If you don’t use hostname customization, users may see a domain name they don’t expect when logging in.

Once the customer is set up, users can be registered for your application in a variety of ways. They can:

• be migrated in from an existing store
• register using social sign-on
• created directly using the API or SDKs
• register themselves if you enable self-service registration

Pick one or more methods that work for your use case; FusionAuth supports them all.

User Authentication

When a user comes to the Ringling site hosted by ClownApp, they must be redirected to a FusionAuth authorization URL with the appropriate client Id and redirect URL. This will be used to start the Authorization Code grant which will authenticate this user. Here’s an explanation of how to create the URL and what each component means.

The user will see a Ringling themed page because of the previous customization and the provided client Id. Other interactions with FusionAuth, such as a “forgot password” email, should be Ringling themed as well.

After the user authenticates and is redirected to the ClownPass application, the client Id and client secret can be looked up in the application database based on the hostname in the redirect URL. The circus ticketing web application handles many client Ids and secrets, one for each customer. The client Id and client secret are provided to FusionAuth to complete the Authorization Code grant. Here’s an explanation of that request.

The tokens contain information about the user and their roles. The ClownPass application can use them to determine correct levels of access or data to retrieve.

User Management

Customer admins and other privileged users will add, read, update and delete user data using the ClownPass application. While there is a lot of user management functionality exposed as an API you could add to your application, common functionality includes:

• resetting a user’s password
• locking a user
• changing user profile data

The application uses the tenant locked API key and an SDK to allow customer admins to perform user management.

Users can manage their own profile and credentials using the self-service account management provided by FusionAuth.

Implementation Notes

Each customer’s users are entirely separate with this tenant based implementation. A person can sign up with the email address jamie.morgan@example.com for both Ringling Brothers and Cirque De Soleil. The person who owns the jamie.morgan@example.com email address may not even know the ticketing application for these circuses are both provided by ClownPass.

Each account is entirely separate with no relation to each other. The accounts can have different:

• profile attributes
• credentials
• roles in applications

Alternative Implementation

The tenant based solution outlined above has distinct user spaces. If you want a shared user space, where the jamie.morgan@example.com user has the same profile data and credentials no matter which circus they are buying tickets for, you need to use a different approach. Instead of separate tenants, have all users in one tenant and model each circus ticketing application as a separate FusionAuth Application configuration. Make sure to build and enforce your own authorization scheme to ensure customer admins from Ringling Brothers couldn’t access Cirque De Soleils’ users, since you can’t use tenant locked API keys.

Here’s a table which shows tradeoffs between these different approaches.

You might want to use one of the alternative options if users must be able to seamlessly purchase tickets from different circuses with a single account. This is similar to the approach of GitHub or Slack.

Expected Outcome

Your web or mobile application has isolated groups of users, one set for each customer. Each user has their own profile data and manages their identity, either in your application or via other login methods such as social sign-on.

Admins can use whatever user management related functionality you choose to expose in your application, using tenant locked API keys to limit access.

Edge Cases

The word tenant can be overloaded. When you are planning for this use case, make sure you distinguish between tenants in your application and FusionAuth tenants. They don’t have to map one to one.

If you have admin users which need cross-tenant access, it can be a challenge to keep their accounts in sync. You can use the API to sync up profile attributes, but some user fields like passwords cannot be retrieved via the API. This can be a challenge for cross-tenant admin users like customer support representatives.

In this situation, you can:

• Have users reset their password every time they need access to a different tenant.
• Use a passwordless login option like a magic link or passkey.
• Set up or use an administrative identity server, such as a second instance of FusionAuth, Google GSuite, or Azure AD/Microsoft Entra, and have these users log in using that.
• Put all admin users in one FusionAuth tenant, create an application in that tenant, and set up an OIDC Identity Provider for applications in other tenants to delegate to that application.

Other Example Scenarios

Any application which has customers who then have their own users or customers is a good fit for this use case.

A very common scenario is a private labelled product sold to SMBs or consumers. Examples include:

• Website builders resold by creative agencies
• Appointment schedulers for hair salons, personal trainers and other service providers
• Private labelled job boards
• Accounting software sold to CPAs and used by the customers they offer tax services to

In each of these cases there is a clear differentiation between the customer organization buying the solution and their end customer. This use case is appropriate when the user identity is not controlled by the customer, but rather by the user themselves.

Additional Documentation

• Multi-tenant guide
• Determining the tenant for a user
• Options for segmenting users
• Theme customization
• Email template customization
• Blog post about private labeling
• Self-service registration
• Self-service account management
• Tenant Scoped API keys