WorkOS, Keycloak or custom .NET? Choosing SSO for your SaaS

Your enterprise customer demands SSO and SCIM. You start searching and within five minutes you have WorkOS, Keycloak and Auth0 on your screen. Plug-and-play SSO. Sounds great.

The real question is what it costs and what you give up for it. Per-connection pricing that grows with your customer base. A separate Java stack your team has to run. Identity data flowing through servers in the US. Below I line up the four options: WorkOS, Keycloak, Auth0 and building SSO yourself in .NET.

What does WorkOS really cost?

WorkOS is a SaaS platform that offers SSO and SCIM as an API. You integrate their SDK and they handle the SAML/OIDC connections with your customers. Setup takes a few hours. That is where the appeal lives.

The price tag is less friendly. WorkOS charges $125 per SSO connection per month. Ten enterprise customers means $1,250 per month, or $15,000 per year. At fifty customers that climbs to $75,000 per year. And SCIM provisioning sits in the Enterprise plan, so add a bit more on top.

You also give up more than money. The connections run through WorkOS, so migrating means re-onboarding every customer. Your identity data flows through their servers in the US. For customers in government, healthcare or finance, that is often a dealbreaker. And the protocol behavior is fixed: custom claims, specific SCIM mappings or non-standard flows only work if WorkOS happens to support them.

Why does Keycloak chafe for .NET teams?

Keycloak is an open-source identity platform by Red Hat. It handles SSO, federation and user management, and plenty more. Free, and proven at enterprise scale. On paper, the ideal escape from per-connection fees.

For a .NET team the sting is in the stack. Keycloak runs on Java (Quarkus). So your team has to deploy, monitor and patch a separate Java application. It is a full application with its own database, its own configuration and its own upgrade cycle. An extra system, then, that you maintain alongside your existing product.

Then there is the complexity. Keycloak can do almost anything, and that flexibility is exactly what makes configuration hard. The admin console has hundreds of options and the learning curve is steep. Your .NET SaaS talks to Keycloak over HTTP, and the moment you want custom logic, you write Keycloak SPIs in Java.

Where does Auth0 / Okta get painful?

Auth0, now part of Okta, is identity-as-a-service. Similar to WorkOS, only broader. Login, MFA, user management and SSO all sit in one platform.

The pain shows up in a few places. Auth0 charges per active user. So with B2B SaaS and thousands of enterprise users the costs add up fast, and the enterprise SSO features sit right in the most expensive plans. The vendor lock-in is the same story as WorkOS: your identity data lives at Auth0 and migrating is a project in itself. And if you only need SSO and SCIM for your existing .NET application? You are paying for a broad platform where you never touch 80% of the features.

What does building custom in .NET give you?

The fourth option gets too little attention: build SSO and SCIM as part of your own .NET application. No external dependency. No monthly per-connection fees.

What you get back is control. The code is yours, so you can modify, extend or switch hosting without migrating anything. Whether you have 5 or 500 enterprise customers, the cost stays the same. Identity data stays in your own database on your own infrastructure, which makes compliance a lot easier. Custom claims, specific SCIM mappings and non-standard SAML configurations you tune to what your customers actually need. And it runs natively in your existing ASP.NET Core application. No Java, no external SDKs.

The price is a one-time investment of 4 to 6 weeks of development. For that you do need knowledge of OAuth2, OpenID Connect, SAML and SCIM. This is not a weekend project.

How do the four compare?

When do you choose what?

There is no winner that fits every case. It depends on your growth, your compliance requirements and how much control you want to keep over a core feature. Three very different questions, with a different answer per situation.

• WorkOS or Auth0 when you need SSO quickly, expect few enterprise customers, and the monthly fees are acceptable.
• Keycloak when your team has Java experience and you want to run a broad identity platform alongside your .NET application.
• Custom in .NET when you expect more than a handful of enterprise customers, data sovereignty matters, or you don't want an external dependency for a core feature of your product.

How many enterprise customers do you expect two years from now? That number often decides whether a per-connection price is smart or expensive.