To choose an SSO provider for a B2B SaaS product, check that it supports both SAML and OpenID Connect, handles one connection per customer without code changes, routes users to the right customer identity provider, provisions and deprovisions users (usually through SCIM), and gives you audit logs. Then look at how its pricing scales (per user, per enterprise connection, or by cluster size), and ask who owns the user directory and whether you can export it. Those last two matter most once you are a year in and want to change something.
“Enterprise SSO” in this context means your customers’ employees sign in to your product with the account their own company manages, through Okta, Microsoft Entra ID, Google Workspace or another identity provider (IdP). The company’s IT team controls who has access, enforces MFA and can switch a person off in one place. This guide is for the team that has to pick the system that makes that possible.
What does enterprise SSO mean to a SaaS buyer?
It helps to separate the two sides of the arrangement. Your customer runs a workforce IdP, and your product is the application that trusts it. The SSO provider you choose sits on your side: it receives sign-ins from many customer IdPs and gives your application one consistent result, so your code does not need a separate integration for each customer.
That is the difference between a feature list that says “supports SSO” and a setup where adding a customer is a configuration task. If you want the underlying definitions first, start with what an identity provider is and OAuth versus SSO.
What should an SSO provider support? A checklist
A logo wall of supported IdPs tells you little, because both SAML and OIDC are standards and any compliant provider should connect to any compliant IdP. These are the capabilities that actually vary:
- Both SAML 2.0 and OpenID Connect. Customers differ on which they run, and SAML vs OIDC explains why you should not pick one for them.
- SP-initiated login as the default, with IdP-initiated SAML available per connection if a customer requires it. The tradeoffs are covered in IdP-initiated vs SP-initiated SSO.
- Domain routing. A user who enters
name@customer.comshould land at the right IdP without a manual picker. - User provisioning. SCIM support for creating and removing users automatically, or at least a clearly documented limit on just-in-time (JIT) provisioning, which creates accounts at first login but cannot remove them. See user provisioning explained.
- MFA and step-up. Ability to require a second factor for sensitive actions, independent of what the customer’s IdP enforces.
- Audit logs covering sign-ins and configuration changes, because enterprise security reviews ask for them.
- Setup effort per customer. Whether adding a connection is configuration your team can do in the provider’s admin console, and whether the provider offers anything a customer’s IT admin can use directly. Check this with every vendor, including us.
The same list shows up in procurement questionnaires, so it doubles as a preview of what your first large customer will ask. For that angle, see SSO doesn’t mean you pass procurement.
How should you compare pricing models?
Compare the model before you compare the number, because the model determines how the bill changes as you grow. We deliberately leave competitor prices out of this post, since they change often and depend on plan and contract. There are three common shapes:
| Model | What grows the bill | Where it tends to hurt |
|---|---|---|
| Per monthly active user (MAU) | The number of users who sign in | Consumer-style growth, or large customers with many seats |
| Per enterprise connection | The number of customer IdPs you connect | Landing many mid-size enterprise customers |
| Infrastructure-based (plan and cluster size) | The capacity you provision to serve sign-ins | Needing capacity ahead of demand, or running spiky login traffic |
Each model suits some products. A product with a few large enterprise customers can do well on a per-connection model, and a product with many small customers and heavy usage may prefer an infrastructure-based one. The mistake is picking on today’s invoice without modelling next year’s customer mix. For vendor-level comparisons, see WorkOS alternatives and Auth0 alternatives.
What questions should you ask every SSO provider?
These questions separate providers whose products look similar on a feature page:
- Who owns the user directory? Where are user records stored, and can you query and export them?
- Can you export your configuration? If you decide to leave, can you take your tenant or realm settings, connections and mappings with you?
- What happens when a customer changes IdP? Moving from Okta to Entra ID should be a configuration change on one connection, not a change in your application. That is the premise of enterprise SSO that survives IdP changes.
- Which token issuer do your apps trust? If your applications trust the provider’s tokens (not each customer’s), swapping upstream IdPs does not touch your code.
- How are upgrades and security patches handled, and who is responsible for them?
- What does a failed sign-in look like to a customer admin? Good error messages and logs cut down support tickets.
Hosted login, hub IdP or build it yourself?
Teams usually end up in one of three places. A hosted login or SDK gets you started fastest and can be enough if enterprise SSO is not yet on the roadmap. Building SAML and OIDC handling yourself gives control but puts security-sensitive protocol code on your own team. A hub identity provider, one that your apps trust and that connects to each customer’s IdP, keeps enterprise connections as configuration instead of code, as discussed in federated SSO versus a single IdP identity hub.
Where does Skycloak fit?
Skycloak provides identity management as a service, with managed Keycloak as the engine today. You get a dedicated identity provider that acts as that hub: one issuer for your applications, SAML and OIDC connections per customer, and upgrades and patching handled by us. If you want to see how Keycloak handles the SSO side, the single sign-on feature page is a good next stop, and the SSO implementation guide walks through connecting a customer end to end.
Frequently asked questions
What is an SSO provider?
An SSO provider is a service or product that lets users sign in once and reach multiple applications. For a B2B SaaS product, it is the system on your side that accepts sign-ins from each customer’s identity provider and gives your application a verified identity.
What is enterprise SSO?
Enterprise SSO lets a company’s employees sign in to a third-party application with the account their company manages, typically through SAML or OpenID Connect, so the company’s IT team controls access centrally.
Do I need both SAML and OIDC?
In practice, yes for B2B. Many large enterprises still run SAML-based setups while others prefer OIDC, and refusing one of them can cost you a deal. A provider that supports both saves you from deciding for each customer.
Do companies charge for SSO?
Often, yes, and how they charge varies: some add SSO to a higher plan tier, some charge per enterprise connection, and some include it in a price based on the plan and cluster size. Ask any vendor how SSO is priced at your expected number of customers, not just at your current one.
Is SCIM required for enterprise SSO?
Not for sign-in itself, but enterprise security teams commonly ask for it because it removes access automatically when someone leaves. Without SCIM, you rely on JIT provisioning, which creates accounts but does not remove them.
How long does it take to add SSO for one customer?
It depends on the customer’s IdP team more than on your software. With a hub identity provider, the technical part can be configuration on both sides, and the calendar time is usually spent waiting for the customer’s admin to exchange metadata and test.