Sam Yapkowitz

I began my career in enterprise software development and got exposure to lots of different frameworks and methodologies. I quickly realized my passion was in the architecture and design of solutions to unique problems. I now get to use these skills to help my customers build high-quality experiences using Okta. When not at work you can find me on the golf course, playing Rocket League or watching football with my friends.

Senior Solutions Engineer

Mark-Vong

Mark is a Staff Product Marketing Manager focused on Technical Marketing at Auth0, where he contributes to the delivery of developer and product focused content. With 8 years of experience in a previous Pre-Sales role, he brings a unique blend of field and customer perspectives on all things CIAM and Auth0. As an avid builder with a background in CS, he continues to develop apps for custom demos and hobby projects.

Staff Product Marketing Manager

Mark Vong

Learn how to build a real-time identity-to-revenue pipeline using Auth0 Inbound SCIM and Event Streams to sync user data to CRMs without external middleware.

Driving Business Outcomes with Auth0 Inbound SCIM and Event Streams

carlos-aguilar

Carlos is a Customer Advocate at Auth0, where he helps guide users and developers to find the right solutions for their needs. He has an eight-year professional background in the SaaS and cybersecurity industries, with extensive experience in customer-facing roles such as account management and customer success management. In his free time, he enjoys hiking and actively seeks out opportunities for outdoor activities and sports.

Customer Advocate

Carlos Aguilar

Lily Wisecarver headshot

As a Senior Product Advocate at Auth0, I am dedicated to championing the developer community. With years of deep expertise in the Identity and Access Management (IAM) space, I empower developers building with our platform by providing technical guidance, creating valuable resources, and channeling their feedback directly to our product and engineering teams. My goal is to streamline the developer experience and help our community implement secure, scalable identity solutions with ease.

Senior Product Advocate

Lily Wisecarver

Learn how to transition your SaaS from social logins to Enterprise SSO using Auth0 Organizations and SCIM for automated user management.

When building a new SaaS product, it's common to start with a familiar social login option like "Login with Google." This works well for individual users, but presents a major roadblock when you attract enterprise clients that manage users under a single corporate account rather than as separate individuals. These clients require employees to access your application using their existing corporate credentials, managed by an Identity Provider (IdP) like Okta or Microsoft Entra ID. This is a standard security requirement to enforce their own access policies.

Simply adding a new Security Assertion Markup Language (SAML) or OpenID Connect (OIDC) login option alongside your existing social login is an architectural mistake. Without a unified identity strategy, your application will not recognize that an employee who signs in with their corporate email (`jane@bigcorp.com`) is the same person who may have previously signed up with a personal Google account using that same email address. This creates a fragmented user experience, where data and permissions are split between two disconnected accounts, breaking the application's functionality for that user.

To build a scalable, enterprise-ready product, your application must allow customers to bring their own user base. You must solve three distinct identity management challenges:

1. **Multi-Tenant Federation:** Architecting your system to connect with multiple external IdPs and correctly associate users with their parent organization.  
2. **Identity Linking:** Creating a seamless process to migrate existing users from social logins to their corporate identities without losing data.  
3. **Automated Lifecycle Management:** Using the [System for Cross-domain Identity Management](https://auth0.com/docs/authenticate/protocols/scim) (SCIM) protocol to automatically provision and de-provision employee access as they join, change roles, or leave the customer's company.

In this guide, we’ll demonstrate how to design a secure, hybrid authentication architecture using Auth0. We’ll show you how Organizations handles multi-tenant federation, how Identity Linking merges social and corporate profiles, and how SCIM automates user lifecycle management. By the end of this post, you'll have a clear strategy for delivering a secure, seamless enterprise login experience without the architectural overhead.

## How Do Auth0 Organizations Enable Multi-Tenancy From Flat User Structures?

While consumer apps (B2C) treat all users the same, B2B clients demand [**tenant isolation**](https://auth0.com/docs/get-started/auth0-overview/create-tenants/set-up-multiple-environments) (the logical separation of one customer’s data and users from all others) to ensure their data remains secure. This becomes tricky when a client wants some employees to use Single Sign-On via Okta, while others use a Social Login like Google. [**Auth0's Organizations**](https://auth0.com/docs/manage-users/organizations) feature is designed for this exact scenario.

Think of an "Organization" as a [container for each business customer](https://auth0.com/blog/managing-auth0-organizations-my-organization-api). It lets you enable any mix of login methods for that single customer: their corporate IdP (like Okta), social logins (like Google), a database you manage, or even a connection to their own user database.

The key benefit is unified visibility. Regardless of how a user authenticates, Auth0 knows they belong to that customer's Organization. This gives you a single view of all users associated with that client, eliminating duplicate accounts and simplifying your application code.

All connection types can be applied globally at the Auth0 tenant level or at the Organization level:

* **[Social Connections](https://auth0.com/blog/deciding-between-social-enterprise-connection):** Adding social logins (like Google) to the container for external or flexible user access.  
* **Enterprise Connections (EC):** Linking the container to corporate IdPs (like Okta) to meet enterprise-grade security requirements.  
* **Database Connections:** Creating a customer-managed user list that lives exclusively inside that specific Organization container.  

By using Organizations, you move the "*Which company does this user belong to?*" logic out of your application database and into your identity layer, simplifying your authorization code.

## How Do You Use “Identifier-First" Login Flow With Home Realm Discovery

One of the biggest friction points when implementing identity for B2B use cases is a cluttered login user interface (UI). You cannot add a "Login with Acme Corp" button for every client. This is where **Home Realm Discovery (HRD)**, an [Identifier First flow](https://auth0.com/docs/manage-users/organizations/login-flows-for-organizations#identifier-first-authentication-with-prompt-for-credentials), is essential.

### How it works

In identity management and user experience (UX) design, **Home Realm Discovery (HRD)** is the process of determining which IdP a user should use to authenticate.

An **Identifier-First** login changes the sequence of the authentication handshake. 

The sequence of the [Identifier-First login flow](https://auth0.com/docs/authenticate/login/auth0-universal-login/identifier-first) in Auth0:

1. **Domain Evaluation:** The user enters `alice@acme.com`.  
2. **Account Lookup:** The identity layer checks if `acme.com` is mapped to an Organization with an active Enterprise Connection.  
3. **IdP Redirect:** If a match is found, the user is automatically redirected to their corporate IdP (for example, Okta) with the correct SAML request.  
4. **Fallback:** If the domain is generic (for example, `@gmail.com`), the system defaults to your standard social or database flow.

### Key advantages

* **Support for Multiple IdPs:** Essential for B2B apps where different customers use different SSO providers.  
* **Security:** It prevents "Password Spraying" (A brute-force attack where common passwords are tested against many different usernames to bypass security lockout policies) because the system only asks for a password after confirming a valid user exists in that specific realm.  
* **Adaptive Auth:** It allows the system to trigger MFA or biometric prompts immediately after the identifier is recognized.

By decoupling the identifier from the password entry, you can support hundreds of enterprise clients through a single, clean email input field that scales dynamically as you add new business customers..

## How to Manage the Data Model With JWTs, Account Linking, and SCIM

Managing backend state adds complexity because it requires constant, manual verification. Writing custom code to check tenant membership for every API request creates a high risk of 'tenant leakage,' which is the accidental exposure of one customer's data to another if that validation logic fails.

### 1. Token validation and context (JWTs)

When offloading authentication, your frontend initiates a context-aware login by passing the tenant ID (Organization):

```JavaScript
// Triggering a context-aware B2B login on the client
const handleB2BLogin = (orgId) => {
  loginWithRedirect({
    authorizationParams: {
      organization: orgId, // Injects the tenant ID into the auth request
      connection_scope: 'openid profile email'
    }
  });
};
```

On your backend, your API then receives a standard [JSON Web Token](https://auth0.com/docs/secure/tokens/json-web-tokens) (JWT) containing an `org_id` claim. Because this claim is cryptographically signed by the IdP, your middleware can trust the user's tenant membership **without making an extra database call** to check their tenancy. This allows you to build a stateless and highly performant authorization layer.

### 2. Merging identities (account linking)

When an existing B2C user (`user@gmail.com`) needs to switch to their company's new SAML connection, you cannot simply create a new user record without orphaning their existing data. This is solved with [**account linking**](https://auth0.com/docs/manage-users/user-accounts/user-account-linking/link-user-accounts). By using an API to link the new enterprise identity to the original user record, you create a unified profile. This preserves the primary `user_id` and ensures all foreign key relationships in your database remain intact.

### 3. Automated provisioning (SCIM)

For enterprise clients, IT departments require **SCIM** to handle onboarding and offboarding at scale. Instead of building custom backend endpoints to parse disparate webhook payloads, a managed identity layer standardizes this. When an IT admin deactivates a user in their central directory (like Microsoft Entra ID), the SCIM protocol pushes that event to your IdP, which can immediately revoke the user's access tokens, a non-negotiable security requirement for most B2B contracts.

## Stop Building Identity Infrastructure From Scratch

Building custom multi-tenant routing, account linking logic, and a SCIM-compliant API are massive engineering investments that divert resources from your core product. By [offloading identity infrastructure](https://auth0.com/blog/how-to-enable-self-service-identity-management-b2b-saas/) to a dedicated platform, you eliminate the maintenance burden and security risks.

**Enterprise Connections, Organizations, and SCIM** are integrated features available on our **B2B self-service plans**. Upgrading gives you the APIs to solve these problems in sprints, not quarters.

* **Ready to start coding?** See production-ready B2B implementations in our official [Auth0 Samples repository](https://github.com/auth0-samples).  
* **Ready to upgrade?** Log in to your [Auth0 Dashboard](https://manage.auth0.com/) to enable B2B features and start testing your first Enterprise Connection today.

### Ready for the next phase?

Choosing the right connection type is just one small part of scaling your identity platform. We know that growth brings complexity, and we’re here to help you navigate it.

Don't let connection confusion slow down your success story. Between our Product and Customer Advocate teams, we are dedicated to helping you succeed as you grow your business. If you have questions about your plan, connections, or growth strategy, please don't hesitate to reach out to [customeradvocate@auth0.com](mailto:customeradvocate@auth0.com).


Moving From Social Login to Enterprise SSO, a Hybrid Auth Guide for Developers

Sheena Allen

Sheena Allan is a Product Manager at Auth0, focusing on Organizations and Self-Service SSO products. She drives strategic planning, product roadmaps, and feature development for B2B SaaS.

Product Manager

Sheena Allan

Learn how B2B SaaS companies can use Tenancy-as-a-Service to scale past the "Identity Wall" and meet enterprise security requirements like SAML and SCIM.

Breaking the "Identity Wall" with Tenancy-as-a-Service


eric wu

With over 7 years of experience in product marketing, I am passionate about creating and delivering impactful marketing strategies that drive customer value, business growth, and competitive differentiation. I have a strong background in launching new products, especially in Security, Generative AI and Cloud domains, where I have led several successful end-to-end product releases. I currently work as a Staff Product Marketing Manager at Okta, a leading identity and access management platform that empowers organizations to securely connect their people and technology.

Staff Product Marketing Manager, Auth0

Eric Wu

Scale your B2B SaaS faster with Auth0 Tenancy-as-a-Service. Automate multi-tenancy, SCIM, and SSO to close enterprise deals without the engineering overhead.

Why Your Growth Strategy Needs Auth0 Tenancy-as-a-Service

gareth-davies

Gareth is the Chief Product Officer at Auth0, where he leads global product strategy and innovation across the Auth0 portfolio. With over 15 years of experience at the intersection of identity, enterprise data, and marketing technology, he is passionate about building secure, scalable platforms that deliver seamless experiences for developers and customers alike.

Chief Product Officer, Auth0

Gareth Davies

Ship B2B applications, now with advanced features like Self-Service SSO, SCIM, and more – for free. 


Auth0 B2B Plans Upgraded: Free Self-Service SSO, SCIM, and More! 

Auth0 for B2B Enhancements accelerates onboarding and streamlines identity management with self-service onboarding workflows, Group Provisioning with SCIM, Universal Logout, and more.

Identity That Helps You Sell: Introducing Auth0 for B2B Enhancements

paulo-nascimento

Paulo Nascimento is a Machine Learning Engineer at Okta, spearheading AI development for the Customer Identity Cloud (CIC). He brings expertise from AI startups to create innovative solutions powering the CIC organization. Paulo's work focuses on integrating AI technologies to strengthen enterprise security, enhance user experience, and drive intelligent automation across Okta's identity platform.

Machine Learning Engineer

Paulo Nascimento

Waleed Manzoul

Staff Product Designer

Automate user lifecycle, enhance security and boost IT efficiency across your enterprise

## Introduction

Consider a Fortune 500 company, like a bank with 40,000 employees. A financial analyst at this company will use many SaaS tools to do their job, like Slack, Google Suite for Work, Zoom, Tableau, Workday, and more. In fact, enterprise organizations rely on [an average of 211 apps each](https://www.okta.com/businesses-at-work/) to run their businesses.

So, the bank’s central IT team might be responsible for managing 200+ SaaS apps, and our financial analyst may need access to a quarter of them. Naturally, for an employee to use all of those apps, accounts for each one would need to be provisioned first.

Fortunately, our bank’s IT team is smart. They utilize [Okta Workforce Identity Cloud](https://www.okta.com/workforce-identity/) to maintain [a directory of all their employees](https://www.okta.com/products/universal-directory/) and enable easy account creation and access to those SaaS apps using [Single Sign-On](https://auth0.com/docs/authenticate/single-sign-on). That means they don’t have to manually provision SaaS apps every time a new employee joins the company or an existing employee needs access.

But what about other events in an employee’s time with the company, such as when they change their role, change their name or pronouns, or eventually leave the company? How many times might those events happen over 40,000 employees? And how might each of those changes be reflected in the SaaS apps that they use?

## User Lifecycle Management Using SCIM

Fortunately, if a SaaS app used at the company relies on a workforce provisioning engine that utilizes SCIM ([System for Cross Identity Management](https://scim.cloud/), a standard for automating the exchange of user identity information between identity domains), that app can synchronize its user list to the central employee directory and react to changes that happen in the directory.

For the bank’s central IT team, this means they can make updates to users once in their central employee directory and have those changes reflected in all of the SaaS apps an employee uses, **reducing administrative overhead and toil**.

The power of this “live” connection that SCIM provides becomes critical when an employee leaves the company. Once central IT deletes this employee from their central directory, any user accounts they had with those SCIM-powered SaaS apps will be deactivated within seconds, **eliminating the chance of unauthorized access** through “[zombie accounts](https://www.wsj.com/tech/cybersecurity/unused-online-accounts-data-safety-38fa675e)” and **maintaining compliance with data privacy regulations**, like [GDPR](https://gdpr-info.eu/art-5-gdpr/).

Timely deprovisioning of former employees can have **cost savings** as well. When an employee leaves, the central IT team can quickly release the employee’s SaaS licenses and accurately reflect the reduced spend to the respective vendors.

So, you can imagine that the bank’s central IT team would want any new SaaS app it evaluates to leverage SCIM due to its many benefits:

* Saves a lot of manual labor
* Improves their security posture
* Saves their company money

## How Does SCIM Provisioning Work?

SCIM works by providing a defined schema of identity data that represents users and groups, along with a REST API that supports JSON and XML for CRUD operations on those user and group resources. 

Behind the scenes, SCIM is broken down into a few core components:

* SCIM Service Provider
    * This service hosts the identity data and responds to SCIM API requests. It’s also commonly called a SCIM server.
    * _Examples: Cloud applications, identity providers (e.g., Okta)_
* SCIM Client
    * The SCIM Client **initiates SCIM requests to interact with a SCIM server to perform operations that manage identities.**
    * _Examples: Identity management systems, HR systems_
* SCIM Schema
    * The SCIM schema defines the structure of identity data.
    * Core schemas: User, Group, EnterpriseUser (defined in [RFC7643](https://datatracker.ietf.org/doc/html/rfc7643))

The SCIM core components then use an HTTP-based REST API that supports JSON and XML data formats, although JSON is more common. The REST API uses standard HTTP methods like GET, POST, PUT, PATCH, and DELETE to support CRUD operations.

SCIM supports a number of key operations, such as:

* User Provisioning
    * The ”SCIM Client” sends a POST request to create a new user, and the ”SCIM Provider” creates the user and returns a unique identifier (ID).
* User Retrieval
    * The ”SCIM Client” sends a GET request with the user ID or search criteria, and the ”SCIM Provider” returns user data that matches the request, provided the user exists.
* User Update
    * The ”SCIM Client” sends a PUT or PATCH request with the updated user data, and the ”SCIM Provider” applies changes and confirms the update.
* User Deprovisioning
    * The ”SCIM Client” sends a DELETE request, and the ”SCIM Provider” removes or deactivates the user account.

On top of this core functionality, SCIM also provides useful features such as: 

* Bulk Operations
    * Where batch processing can be applied for multiple SCIM operations in a single request
* Filtering and Searching
    * Allows complex queries to find specific users or groups by using a standardized filter syntax

For each request, the SCIM REST API will return with the appropriate HTTP status to indicate success or failure along with detailed error messages for troubleshooting. SCIM typically uses OAuth 2.0 for authorization and supports HTTPS for secure data transmission.

SCIM is also extensible, which means that organizations can extend the standard SCIM schemas to accommodate their specific needs. For example, if an organization wants to include additional information about employees not covered by the standard SCIM schemas, then they can store additional information such as ”department” or ”manager” in their user profiles.

## SCIM vs SAML

Security Assertion Markup Language (SAML) is an XML-based framework for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It’s most commonly used to enable Single Sign-On (SSO) across different web applications and services.

SCIM and SAML are both protocols for identity and access management (IAM). However, they serve different purposes. 

SCIM is used for user provisioning and management across different systems and applications, ensuring that identity data is consistent across. SAML, on the other hand, is used to access multiple applications with a single set of credentials.

> In summary, SCIM is for user management, while SAML is for user authentication.

## SCIM vs. SSO

Single Sign-On (SSO) is an authentication method that allows users to sign in to multiple applications with a single set of credentials.

Although SCIM and SSO are related, SCIM is a protocol used for provisioning appropriate roles and groups to users, whereas SSO authenticates those users into multiple accounts with a single set of login credentials.

## Inbound SCIM with Auth0

If you’ve been reading about SCIM online, you’ve probably found identity providers like Okta Workforce Identity Cloud and Microsoft Entra ID support SCIM in different ways, and that building for each of them can become a substantive effort. We’d advise that you learn about the identity providers your customers use and tailor your SCIM solution to meet the majority of your customers. However, If you think you will need to integrate your development with more than one identity provider, don't despair: there are solutions that allow you to easily connect to multiple identity providers at once. 

In fact, that's one of the things we do at Auth0. Our [Inbound SCIM solution](https://auth0.com/docs/authenticate/protocols/scim) allows you to integrate with Okta Workforce Identity Cloud, Microsoft Entra ID, and other identity providers via both SAML and OpenID Connect, manage attribute mappings on a per connection basis, and more. 

## Conclusion

SCIM is a powerful way to automate user lifecycles and maintain user accounts across platforms that can save companies time, money, and increase their security. Learn more about SCIM by exploring the [Auth0 docs](https://auth0.com/docs/authenticate/protocols/scim). 


"scim"