I support SSO as well, and have in previous roles, and support costs did not drive SSO pricing.

One way you can see this is the case is that there are stiff SSO taxes from some vendors who don't even do custom SSO, just OIDC.

The major identity support cost is 2FA, because people constantly lose it, and you need to design and manage an account recovery process.

To add an anecdote from the other perspective, I was the PM for the authn/z capabilities of a big enterprise platform.

SSO was one of the greatest support burdens due to the numerous protocols we supported and the vast array of sometimes bizarre, often complex auth environments across the customer base.

The biggest hidden cost came from the complete lack of consistency in auth implementations from 3rd party vendors, i.e. it wasn’t enough to implement the SAML/OIDC/etc specs, because many of the systems our customers wanted to connect with had not implemented to spec.

This is all prior to dealing with 2FA which was definitely another major factor.

If you just supported OIDC, you'd still have upcharged for it, at least unless you had an ideological reason not to (we don't, for ideological reasons, but I sort of rue that decision).

I realize in retrospect my comment was probably confusing as written.

The company didn’t charge extra for SSO despite the support cost, also for ideological reasons. But they were also singularly focused on large enterprise customers so it was table stakes. Plenty of other platform modules to upsell.

My point was mostly to highlight that it can be costly for a bunch of reasons.

But with SSO you can offload all the 2FA handling to the IdP.

Most customers did. But due to a wide variety of customer types and various hybrid auth environments, we had to support 2FA directly in-platform as well.

There were also privilege elevation scenarios to consider, e.g. to access highly sensitive data, the current authenticated user must enter a 2nd factor to continue.

> The major identity support cost is 2FA, because people constantly lose it, and you need to design and manage an account recovery process.

Some of this is self-inflicted, e.g. a few of my banks only support 2FA via their own apps, so while I'd never lose my TOTP code, it's a hassle every time I lose my phone. (Or it breaks, is stolen, etc.)

But for enterprise SSO they get to handle all that right? That’s a pure win for your support burden.

Yes, that's my point.

I ran a company that did price segmentation on SSO, and it's the other way around. The burden of supporting the buggy piece of crap that is SAML SSO is the cost of the privilege of being able to perform such sharp segmentation.

Except the segmentation isn't all that sharp. With Google domains et al almost everyone wants SSO now, even the smallest of companies.

It's not that small companies don't want it, it's that they're capable of not getting it. Larger companies aren't: one thing their SOC2 auditors will actually be able to evaluate is whether all their vendors do SSO.

It's segmented even in OSS software to the point where it's the first thing I have to check when deciding what software is going to run on my home server.

Agree, I have implemented a few provider and every time they implemented their own interpretation of the spec. In the end you end up checking each provider to make sure everything works as expected.