Enterprise SSO for B2B SaaS: How to Prepare Before Your First Big Customer Asks

Enterprise SSO for B2B SaaS often becomes a requirement as your product attracts larger customers. A prospect may be ready to move forward, only for its IT team to ask: Can our employees sign in using our existing identity provider?

While smaller customers may be comfortable with email and password authentication, larger organizations typically use providers such as Microsoft Entra ID, Okta, or Google Workspace to manage employee access and security policies.

Supporting enterprise Single Sign-On (SSO) lets employees authenticate through their company's existing system while making your product easier to adopt. Preparing early gives your team time to design the integration, support SAML and OpenID Connect (OIDC), and build a reliable onboarding process. Keycloak provides an established foundation for implementing these capabilities.

TL;DR

Enterprise SSO for B2B SaaS allows employees to sign in to your product through their company's existing identity provider, such as Microsoft Entra ID, Okta, or Google Workspace. To prepare before your first large customer asks for it, plan your SSO architecture, support the SAML and OIDC protocols, establish tenant-specific identity provider configurations, and test the complete authentication flow.

Here are the main things to prepare:

• Choose your protocols: Understand when SAML 2.0 and OpenID Connect (OIDC) are appropriate for your enterprise integrations.
• Design for multiple organizations: Give each customer a way to configure its own identity provider without affecting other tenants.
• Connect identity providers: Plan how your SaaS exchanges authentication information with enterprise identity systems.
• Map user identities: Define how external identity information connects to user accounts and organization membership inside your application.
• Plan access management: Establish how your product handles account creation, role assignment, session management, and user deactivation.
• Test the complete flow: Cover successful logins, authentication failures, certificate changes, expired sessions, and other important scenarios.
• Use an established identity platform: Keycloak supports SAML and OIDC, giving your team a foundation for implementing enterprise authentication.

Building enterprise SSO into your architecture early makes future customer onboarding easier and gives enterprise IT teams a more familiar way to manage access to your product.

Why Enterprise Customers Expect Single Sign-On

When a company has dozens or hundreds of employees using the same SaaS product, managing individual passwords becomes an administrative concern. Its IT team needs a consistent way to control access, enforce authentication policies, and respond when employees join or leave the organization.

Enterprise SSO addresses several of these requirements.

Employees use their existing company accounts

Most established organizations already have an identity provider that handles employee authentication. Microsoft Entra ID, Okta, and Google Workspace are common examples.

When your SaaS supports enterprise SSO, employees can authenticate through the identity provider their organization already uses. They don't need to maintain a separate password specifically for your application, and the company can apply its existing authentication policies to the sign-in process.

For employees, this creates a more familiar login experience. For IT administrators, it reduces the number of separate authentication systems they need to manage.

IT teams retain control over authentication policies

Enterprise organizations often enforce security requirements across their applications. These can include multi-factor authentication, conditional access, approved authentication methods, and restrictions based on organizational policies.

When employees authenticate through their company's identity provider, its configured authentication policies are enforced during the sign-in process. Keycloak receives the authentication result from the customer's identity provider and passes the authenticated identity to your SaaS application. The organization continues managing its own authentication requirements through its existing identity system.

This is an important part of enterprise SSO for B2B SaaS: your product becomes part of the customer's existing identity environment.

Enterprise SSO is a factor in purchasing decisions

Enterprise buyers evaluate more than product features. Their security and IT teams also examine how an application fits into existing infrastructure, how employees authenticate, and how access is controlled.

If a prospect already uses an identity provider across its organization, the absence of SSO introduces additional work for its IT team. That friction can appear during technical evaluation, security reviews, or procurement.

Supporting enterprise SSO doesn't automatically guarantee a deal, but it removes an important integration barrier and makes your product easier to adopt within larger organizations.

SAML vs. OIDC: Understanding the Two Enterprise SSO Protocols

Before implementing enterprise SSO for B2B SaaS, your team needs to understand the two protocols customers are most likely to request: Security Assertion Markup Language (SAML 2.0) and OpenID Connect (OIDC).

Both allow an application to rely on an external identity provider for authentication. However, they use different mechanisms to exchange identity information and establish an authenticated session.

SAML 2.0: A common choice for enterprise identity integrations

SAML 2.0 is an XML-based authentication protocol widely used in enterprise environments. It allows a service provider to rely on an identity provider to authenticate users. In a direct integration, your SaaS application acts as the service provider. When using Keycloak as an identity broker, Keycloak takes that role when connecting to the customer's external identity provider.

After authenticating the user, the identity provider sends a signed SAML assertion to Keycloak. The assertion contains information about the authentication event and the user's identity. Depending on the configuration, it can also include attributes such as an email address, username, and group information.

SAML is an important protocol to support when selling to organizations that already use established enterprise identity infrastructure. Many IT teams have existing SAML configurations and expect new business applications to integrate with them.

OpenID Connect: An identity layer built on OAuth 2.0

OpenID Connect is an authentication protocol built on top of OAuth 2.0. It allows applications to authenticate users through an identity provider and receive standardized information about their identities.

OIDC uses JSON Web Tokens (JWTs), including an ID token that contains claims about the authenticated user.

OIDC is widely used in modern web and mobile applications because it integrates naturally with OAuth 2.0-based systems and token-driven authentication architectures.

Which protocol should your SaaS support?

The answer depends on the identity providers your customers use and the integrations they expect. Some enterprise customers will request SAML, while others will prefer OIDC. Supporting both gives your SaaS more flexibility when working with organizations that have different identity infrastructures.

For a B2B SaaS product preparing for enterprise customers, supporting both protocols is a practical architectural goal. Your application can provide a consistent login experience while allowing each organization to connect through the protocol supported by its identity provider.

Design Your SSO Architecture for Multiple Organizations

Supporting enterprise SSO becomes more complicated when your SaaS serves several organizations. Each customer has its own identity provider, authentication policies, users, and configuration requirements. Your implementation needs to support these differences while keeping every organization's access isolated.

This is where multi-tenant architecture becomes important. Your application should know which organization a user belongs to, which identity provider handles that organization's authentication, and how the authenticated identity maps to an account inside your SaaS.

Give each organization its own identity provider configuration

A common mistake is treating enterprise SSO as one global integration. Your first customer might use Microsoft Entra ID, while another uses Okta and a third uses Google Workspace. Each organization needs its own connection details and authentication settings.

Your SaaS should store an SSO configuration for each organization. Each organization's configuration should include the relevant details for its selected protocol:

• Identity provider: The provider used by the organization, such as Microsoft Entra ID or Okta.
• Protocol: Whether the connection uses SAML 2.0 or OIDC.
• Client or service provider details: Identifiers and endpoints used to establish the integration.
• Certificates and signing keys: Information used to validate signed authentication messages or tokens.
• Attribute mappings: Rules for connecting identity provider claims or attributes to your application's user fields.
• Connection status: Whether the integration is configured, enabled, or temporarily disabled.

Keep these settings associated with the correct tenant. A configuration change made by one customer's administrator must not affect another organization's login experience.

Keep tenant boundaries intact

An authenticated user should only enter the organization associated with their account and SSO configuration. This requires more than successfully validating a SAML assertion or OIDC token.

Your application must check the relationship between the authenticated identity and the tenant requesting access. A valid identity from one organization must not grant access to another organization's data or administrative functions.

For example, imagine an employee belongs to two customer organizations that both use your SaaS. Your system needs to resolve the correct tenant context during login and enforce the appropriate permissions after authentication.

Treat tenant identification, user authentication, and application authorization as separate responsibilities. This makes it easier to support customers with different identity providers without weakening access boundaries.

Map Enterprise Identities to Your SaaS User Accounts

Once Keycloak authenticates an employee through the customer's identity provider, your application needs to determine which local user account should receive the authenticated session. This step is easy to underestimate, but incorrect identity mapping can lead to duplicate accounts, unexpected access, or users being associated with the wrong organization.

An enterprise identity contains claims or attributes that describe the authenticated person. Your application needs consistent rules for interpreting that information and connecting it to its own user records.

Choose a stable identifier for each user

Email addresses are commonly included in SAML assertions and OIDC tokens, so they are often used during account matching. However, email addresses can change when employees move between departments, update their names, or receive a new company address.

If your application uses OIDC with Keycloak, use the combination of the issuer (iss) and subject (sub) claims from the Keycloak-issued ID token as the stable identifier for each user. If your application uses SAML, use a stable subject identifier from the Keycloak assertion, such as a persistent NameID. Keycloak maintains the relationship with the customer's external identity provider separately.

Store the identity reference received from Keycloak alongside the local user account and the organization to which it belongs. This gives your application a reliable way to recognize the same user during future sign-ins.

Define which identity attributes your application needs

The customer's identity provider can send several attributes or claims to Keycloak. Your application should only consume the information it actually needs, based on the attributes Keycloak maps and exposes through its client tokens or assertions.

Common examples include:

• Email address: Useful for communication and account display.
• Display name: Helps identify the employee inside your application.
• First and last name: Useful when your product maintains separate profile fields.
• Groups: Can provide information about organizational membership or group assignments when Keycloak is configured to map and expose those claims.
• Unique subject identifier: Connects the external identity to the correct user account.

The exact attributes available depend on the identity provider and its configuration. Your integration should define the required attributes clearly and handle missing optional information without breaking authentication.

Keep authentication separate from application permissions

A successful SSO login confirms that the identity provider authenticated the employee. It doesn't automatically determine what that employee can do inside your product.

Your SaaS still needs its own authorization model. A user might authenticate successfully through their company's identity provider but have permission to view only a limited set of resources within the application.

For example, an enterprise customer might have employees in finance, support, and engineering. The identity provider can communicate group information, while your application maps those groups to roles such as billing administrator, support agent, or read-only user.

Define how external groups and claims map to your internal roles. Also establish what happens when a user's group membership changes, an attribute disappears, or an administrator removes an application role. These rules should be explicit so authentication and authorization remain predictable.

Prepare Your Keycloak Architecture for Enterprise SSO

Keycloak supports SAML and OpenID Connect and can act as an identity broker between your SaaS application and your customers' identity providers. This gives your team a central place to manage external identity connections and authentication flows.

Decide how to represent customer organizations in Keycloak

Keycloak offers two main approaches to organizing enterprise customers: separate realms for individual organizations or a shared realm using its Organizations feature.

With a separate realm per customer, each organization has its own identity providers, users, clients, roles, and authentication settings. This provides realm-level configuration separation but increases administrative overhead as your customer base grows.

With a shared realm, Keycloak's Organizations feature lets you represent each customer as an organization and link it to its own identity provider and email domain. Introduced as a technology preview in Keycloak 25 and fully supported starting with Keycloak 26, this feature is designed for B2B multitenancy and allows multiple organizations to share the same realm and applications.

Choose the structure that fits your tenancy model, customer isolation requirements, and expected number of organizations. Your application must still enforce tenant boundaries and permissions after Keycloak authenticates the user.

Implement SAML and OIDC Connections in Keycloak

Once your architecture is defined, connect each customer's identity provider to Keycloak. Both protocols follow the same general process: establish trust, configure user identification, and pass the authenticated identity to your application.

Configure a SAML identity provider

Your customer typically provides SAML identity provider metadata containing its entity ID, SSO endpoint, and signing certificate. Keycloak provides the corresponding service provider metadata, including the assertion consumer service (ACS) URL and SP entity ID, which your team shares with the customer so they can register Keycloak in their identity platform.

In Keycloak, create a SAML identity provider and import the customer's metadata or enter the values manually. The customer must also register Keycloak as a service provider in their identity platform.

Before enabling the connection, configure Keycloak to validate the issuer, audience, recipient, destination, signature, and assertion conditions. Ask the customer to configure a persistent NameID format so the user has a stable identifier across sign-ins. Microsoft Entra ID commonly uses an email address as the NameID unless configured otherwise. Since email addresses can change, using an email-based NameID can break account matching when an employee's address is updated. Also configure identity provider mappers to map the required SAML attributes to the corresponding Keycloak user fields. Your application can then consume the identity information Keycloak exposes through its client tokens or assertions.

Configure an OIDC identity provider

For OIDC, your customer typically provides an issuer URL, client ID, and client secret. Keycloak uses the provider's discovery document to retrieve its authorization, token, user information, and signing-key endpoints.

Create an OpenID Connect identity provider in Keycloak and enter the connection details. Request the openid scope, adding profile or email when your application needs those claims.

Test the authorization code flow and confirm that Keycloak validates the external provider's ID token, including its issuer, audience, subject, and signature. Then verify that Keycloak maps the user's identity correctly and that your application validates the tokens or session it receives from Keycloak.

Handle First Broker Login and Account Linking

When a user signs in through an external identity provider for the first time, Keycloak runs its First Broker Login flow. This flow handles the creation of a new Keycloak account or the linking of the external identity to an existing account.

If Keycloak finds an existing local account with the same email address, the configured flow can ask the user to verify ownership of that account before linking the external identity. This prevents an external identity from being linked to an existing account without the required verification.

Pay attention to the Trust Email setting in the identity provider configuration. Only enable it when you trust the identity provider's email verification and control the relevant domain. If an incorrectly configured or untrusted identity provider can assert an email address as verified, enabling this setting could allow someone to take over an existing account associated with that address.

This is an important part of enterprise SSO onboarding because many customers already have users in your SaaS before enabling SSO. Your implementation needs a clear account-linking policy to avoid duplicate accounts and unauthorized account associations.

Connect the authentication flow to your application

Your application must direct each user to the correct organization-specific login flow. For example, a URL such as /login/acme can identify the organization, allowing your backend to initiate authentication through the corresponding Keycloak identity provider. When building the authorization request, include the kc_idp_hint parameter with the alias of the configured identity provider. Keycloak then redirects the user directly to that provider, skipping its default identity provider selection screen.

You can also offer an organization selector or use email-domain discovery to identify the appropriate login option. With Keycloak Organizations, you can configure automatic identity provider redirection based on a verified email domain. Treat domain discovery as a routing mechanism, not proof of identity or authorization, since domains can be shared across organizations.

After authentication, validate the result and establish the application session. Keep the organization context attached to that session so your backend can enforce the correct tenant boundaries on subsequent requests.

Secure and Test Your Enterprise SSO Implementation

Enterprise SSO affects access to customer data, so a successful login test is only the beginning. Your implementation needs to handle invalid responses, account changes, interrupted sessions, and configuration updates without creating unexpected access.

Validate the full authentication flow

Test the complete journey for both SAML and OIDC, including the initial redirect, identity provider authentication, callback, identity mapping, and application session creation. A test that stops after Keycloak authenticates the user can miss problems in your own tenant-resolution or account-provisioning logic.

Build test cases around situations your customers are likely to encounter:

• Successful login: An authorized employee signs in through the correct company identity provider.
• Unknown organization: A user attempts to sign in through an organization that has no configured identity provider.
• Unassigned user: Authentication succeeds, but the user is not authorized to access your SaaS organization.
• Invalid or expired response: The application receives an expired assertion, invalid token, or failed signature validation.
• Disabled employee: An employee whose access has been revoked attempts to sign in again.

These cases help uncover issues that a basic happy-path test will not reveal. They also give your team a repeatable checklist for onboarding the next enterprise customer.

Protect the connection and application session

Use HTTPS for authentication endpoints and callbacks, and protect client secrets and signing keys as credentials. Avoid placing secrets in frontend code, logs, screenshots, or support tickets. Restrict administrative access to identity provider configurations, and record important changes so your team can investigate unexpected authentication behavior.

Your application should also enforce tenant authorization after authentication. A valid identity provider response confirms that a user authenticated; it does not automatically grant access to every organization or resource in your SaaS platform. Check the user's organization membership and application permissions on every relevant request.

Session behavior deserves attention too. Define how long application sessions remain valid, how users sign out, and what happens when an administrator disables an account. SAML Single Logout and OIDC logout mechanisms have provider-specific behavior, so test the flow with the identity platforms your customers actually use. Your application should have a clear session-revocation strategy even when a customer's identity provider cannot immediately terminate an existing SaaS session.

Managing Enterprise SSO with Skycloak

Building enterprise SSO into a B2B SaaS product requires more than connecting an identity provider. Your team also needs an identity infrastructure that can handle authentication, user federation, organization-specific configurations, and ongoing administration.

Keycloak provides the foundation for this architecture. It supports SAML and OpenID Connect, offers identity brokering for external providers, and gives your team control over authentication flows and identity management. You can use it to connect customer identity providers while keeping your SaaS application responsible for its own tenant permissions and business logic. Skycloak also provides managed Single Sign-On infrastructure for teams implementing enterprise authentication.

Running Keycloak yourself also means taking responsibility for its infrastructure, upgrades, availability, backups, and operational maintenance. Those responsibilities can become harder to manage as more enterprise customers request dedicated identity provider configurations.

Skycloak provides managed Keycloak hosting for teams that want to use Keycloak without managing the underlying infrastructure themselves. Your team retains full Keycloak admin access, so you can configure identity providers, authentication flows, clients, and realms according to your application's architecture.

A few Skycloak details are worth knowing:

• Unlimited users on all plans: Your Keycloak deployment can support your user base without a per-user hosting limit.
• Full Keycloak admin access: Your team can manage its Keycloak configuration directly.
• Multiple deployment regions: Choose from the US, EU, Canada, and Australia.
• Realm exports: Keep exports of your realm configuration for backup and migration workflows.
• 21-day free trial: Explore the platform without providing a credit card.

For a SaaS team preparing its first enterprise SSO integration, managed Keycloak hosting can reduce the infrastructure work involved in operating the identity layer. Your developers can focus more of their time on customer-specific SAML and OIDC connections, account mapping, tenant authorization, and the login experience inside the product.

Explore Skycloak's pricing and plans to compare the available options for managed Keycloak infrastructure.

Frequently Asked Questions

Should a B2B SaaS product support both SAML and OIDC?
Supporting both protocols gives enterprise customers more flexibility. Many established organizations use SAML-based integrations, while newer identity platforms and applications commonly support OIDC. Keycloak supports both, making it possible to connect customers through their preferred protocol while maintaining a consistent authentication layer for your application.

Can Keycloak connect multiple enterprise identity providers?
Yes. Keycloak supports identity brokering with multiple external identity providers, including SAML and OIDC providers. You can configure separate connections for different customer organizations and route users to the appropriate provider through organization-specific login links, an organization selector, or domain-based discovery.

Should every enterprise customer have a separate Keycloak realm?
Not necessarily. A separate realm can provide stronger configuration isolation between customers, but it also introduces additional administration as the number of organizations grows. A shared realm with multiple identity providers can simplify centralized management, provided your application has reliable organization resolution and tenant isolation. Choose the model based on your security boundaries, operational requirements, and expected customer scale.

Does enterprise SSO automatically provision and deactivate user accounts?
No. SSO handles authentication, while provisioning and deprovisioning require additional logic. Your application needs rules for creating accounts, assigning organization membership, updating user attributes, and revoking access when employees leave a customer organization. SCIM can automate user and group provisioning when the customer's identity provider and your application support it.

Can I add enterprise SSO after launching my SaaS product?
Yes, but adding it later can require changes to your existing authentication and account model. You may need to introduce organization-level identity provider configurations, link external identities to existing accounts, and update your login and session flows. Preparing your data model and tenant architecture early makes the integration easier when your first enterprise customer requests it.

Final Thoughts

Enterprise SSO is easier to deliver when your SaaS architecture accounts for it before a major customer makes it a purchasing requirement. You need a clear tenant model, reliable identity mapping, support for SAML and OIDC, and a secure authentication flow that works across different enterprise identity providers.

Keycloak gives you a flexible foundation for those integrations. The important work is making sure each customer connects to the right identity provider, each authenticated user maps to the correct organization, and application permissions remain under your control.

You do not need to build every enterprise identity feature before launch. Start with an architecture that can support multiple organizations, establish a repeatable process for onboarding identity providers, and test the failure cases alongside successful logins. That preparation will make your first enterprise SSO integration much easier to deliver and give your product a stronger foundation for the customers that follow.