Vendors that treat single sign-on as a luxury feature
sso.tax281 points by vinnyglennon 2 days ago
281 points by vinnyglennon 2 days ago
This pops up on HN about once a year, and it's worth calling out that the SSO tax has mostly nothing to do with technology or with support costs and mostly everything to do with market segmentation. One of the clearest segmentation signals you get is that bigger, less price-sensitive customers all require SSO (because their SOC2 attestations require it).
You can get irritated about pricing systems that soak price-insensitive customers, but remember that the big price-insensitive customers pay for the price-sensitive customers, which is why this kind of segmentation is practically universal.
Previously, on this, from me:
> but remember that the big price-insensitive customers pay for the price-sensitive customers
The fallacy is thinking that the alternative is for everyone to pay the lower price and get the enterprise features.
In reality, without market segmentation a singular price for everyone would fall much closer to the enterprise price than the non-enterprise price.
You can call it an SSO tax, but it would be equally correct to refer to the lower price as the non-corporate discount.
> In reality, without market segmentation a singular price for everyone would fall much closer to the enterprise price than the non-enterprise price.
That totally depends on the relative elasticity of supply and demand.
It’s not very intuitive, but price discrimination (usually) results in too much demand for a good/service and a deadweight loss of consumer surplus. In the worst case scenario all consumer surplus can be arrogated to the producer, and an extreme oversupply of the product. Imagine a cheap drug that could be sold for whatever amount of money the consumer had available.
Price discrimination allows producers to capture consumer surplus from consumers with a greater WTP than the otherwise price, and to offer the product at a lower price to those with a lower WTP.
In a monopoly, this means that the quantity supplied may be greater, but it would still be no greater than under perfect competition (necessarily so since the monopolist would never offer the product at a lower price than their MC, which is where price would be under PC). You can see this because there is no consumer that would buy under price discrimination that wouldn't buy under PC, and everyone with a WTP greater than MC buys either way.
Anyway, I agree that price discrimination results in the producer capturing more consumer surplus, but it can potentially be beneficial for those with a lower WTP in return for hurting those with a higher WTP.
There are many arguments I've heard about price discrimination being annoying, but deadweight loss is not one of them. Quite the opposite, fixed prices in the presence of undeserved pricing power results in a less than socially optimal amount of production, and price discrimination tends to reduce that.
To say nothing of the implicit argument that software service providers have undeserved pricing power; I think that's begging the question, but it's not really relevant to my quibble here.
Are you saying companies should provide a discount for not using SSO?
Or charge everyone the enterprise price to remove segmentation altogether?
Edit: I think I see what you’re saying. Although you’d likely welcome the same criticism if you refer to it as the non-corporate discount.
> Although you’d likely welcome the same criticism if you refer to it as the non-corporate discount.
Why? eg no one questions students discounts.
I’m not saying it’s a bad idea.
Only saying it won’t satisfy the people who don’t like the “SSO tax”.
There’s no difference between giving someone a discount vs. charging them less in the first place without a discount.
It’s semantics. It wouldn’t actually change what people end up paying at the end of the day. It’s just framed as a discount instead of an upsell.
Like if airline charged first class prices, but gave a “discount” for accepting an economy seat. (Same thing, just framed differently)
Why not? Just like some companies offer discount plans that come with no/very limited tech support, and others charge 10 or 20x for the same product bundled with a high level of support.
Most of the big players like Microsoft charge enterprise customers for support on top of everything else. And this "premium support" still sucks. Microsoft outsources to Accenture who then outsource again to some random dopey small companies in the middle East so you get calls in the middle of the night from Qatar by someone who has no more knowledge than what the docs say. Which you've already read yourself otherwise you wouldn't have gone through the hassle of logging a ticket. Because outsourcing causes barriers between the people who built the thing and the people who support it.
In most of these cases we either give up because the support is so useless, or someone high up calls Microsoft and gets the case escalated away from Accenture to someone in Microsoft who actually knows something.
Personally if I were a CIO I would really be pissed at having to pay for this kind of "support". But yeah these guys rub shoulders with Microsoft all the time who tell them it's all amazing.
I like Patio11's characterization[0]:
> The right way to think of the "SSO tax" (where companies charge extra for security features) is "You are being offered a dual use product backed by a strong engineering team for far less than it would otherwise cost, with sophisticated enterprises picking up the slack."
That said, TLS/SSL used to be the preserve of the enterprise too (or at least the ecommerce site).
There are lots of free options, including 3rd party servers and libraries. I'm hoping eventually SSO will be, if not in free versions, at least not isolated to enterprise plans.
Many "softer" forms of SSO have trickled down too. Google + Microsoft OAuth are ubiquitous today without any upchage. OAuth from a Google Workspace account managed by an IT admin has many of the same security guarantees as SAML or OIDC from a Google Workspace account, at least for a small player. There are some sketches like https://easie.dev/ that explore this further.
> and it's worth calling out that the SSO tax has mostly nothing to do with technology or with support costs
I'm surprised this is at the top. My experience, and the experience of nearly all the commenters below, is that SSO is by far the biggest support burden they have.
SSO costs extra because it costs extra to support them. Market segmentation is a nice side effect though.
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.)
> mostly nothing to do with technology or with support costs
Support costs aren't zero though. I work for a company with a lot of corporate customers and we get loads of SSO support tickets. People are always misreading the docs, (mis)configuring things against our recommendations, migrating systems, merging systems (due to acquisition etc)...
Also, enterprise customers are way more work, the sales cycle is longer, the compliance and onboarding stuff takes more time. There's a very legitimate case for building that into one's pricing, and it's really the same reason these companies appear price insensitive. If they had people lining up to give them a better price, they'd presumably take it.
I run a very small business, SSO is still very high up on my feature priority list, and I have passed on software/services I would have otherwise used for competitors that offered SSO at a lower entry-point.
We have Github Enterprise licenses for all our developers. All 7 of them.
Similar with other services.
Just because of SSO, as we don't have the manpower to handle the compliance stuff our customers demands otherwise.
Can you clarify, are you suggesting that the bills footed by large orgs that require SSO are paying the bills for these features?
I think the implication is that without a few whale customers, the minimum price would be significantly higher for everyone. The SSO whales subsidize everyone else.
I sort of feel that the way most software pricing works is that it is the big customers who pay for features in everything and the small customers get brought along for the ride, in short I think it's the same as SSO for basically all functionality.
I expect like any industry, most SaaS operations are floated by a smaller number of whale customers, and everyone else is running a lot closer to (or at) break even in terms of cost, but serve as advertising, testing, and vendor-validation that allows that next whale to pull the trigger.
It's true both in the micro sense ("We wouldn't have developed the headache that is SSO without a cornerstone customer demanding it and paying $XXXk"), and in the macro sense ("Our business would not be a going concern without the significant revenue provided by enterprise customers")
Interesting. I wouldn't have thought that running an SSO integration is that painful. I've done it before, albeit for a single enterprise client, and while annoying at first, after delivery was just like another feature.
The real issue is not the first one, the issue is the 2nd and 3rd, and 10th, will all have some minor idiosyncrasy. There are other posts in this thread that discuss it more in depth - I have only enough personal experience to know that this particular stove is hot.
I don't think SOC2 specifically demands SSO and just encourages it. Probably good, since such security mandates often age badly, even such a broad concept like SSO could fall victim. And there is always that one tool that isn't integrated, ironically inhouse software often neglects it.
But otherwise I believe you are very on point. Although from a developer perspective perhaps it should be segmented the other way around. If I can outsource to identity providers, I have delegated a lot of risk and work. And while the initial implementation might be a bit more cumbersome, in the long run it certainly is less development intensive than providing a complete user management interface. And maintenance for a few keys is easier than user management, even if you still have to do some of that.
Perhaps not using SSO should be marketed as some privacy focused benefit, which is more expensive.
It doesn't specifically demand it, but (1) SSO is the simplest way to knock out a huge swath of control objectives, and (2) once you attest to a control like SSO, it's extremely annoying to pull that back. If you hire security/compliance/engineering management to take you through SOC2 and they don't set up and attest to SSO, they're bad at their job.
Security is an optional feature? You must be a sales executive...
SSO doesn't add security, it enables bulk management of accounts. Which only affects security in an indirect way.
Technically it doesn't add security, but I think the recommendation for SSO stems from the reality that peoples behavior gets worse if they have to maintain more accounts. And if they use the same password, the least secure system affects the others in a classical setup.
I hate this argument. The local PTA or kids sports league or boutique needs sso as much or more than an enterprise. These may be organizations without an IT department at all, handed down from family to family, where they are transferring a database of gmail passwords. I know gsuite and office365 have free tiers for charity, but the amount of small businesses with a gmail address is staggering.
SSO should be a feature for the family as well. A parent should be able to pull up a dashboard and see where all their family gmail accounts are authorized to use as a login from one screen without scrolling.
The overall sentiment that SSO creates a support burden is true, but a separate problem that should also be fixed. it _shouldnt_ be complicated for a small team with ten accounts to control group login information, revoke access, lock accounts.
As someone who does a lot of local organizing, I really don't think getting SSO set up in this level of organization is a thing that happens enough to impact pricing decisions at Atlassian. Even if SSO was completely free everywhere, most of these kinds of places would still just be using a single shared account with a shared password.
Stuff costs money! That's really all there is to the analysis. You can demand that companies not price-segregate customers, but then all you're really saying is that there's no account that the local PTA can afford, because you're demanding that vendors raise prices on the low end and and drop them for customers like Apple and Ford.
Thank you for adding some sanity to this discussion – this is ultimately a matter of economics, and the R&D effort to add and maintain these features is not trivial.
I think you missed the point. The costs isn't insomuch R&D, it's in support. Users struggle with SSO and so we get tickets; techs answering tickets costs money.
On the other hand you have dev time that needs to save user passwords in a secure way. And this is the part of software that requirements maintenance and updates.
Sure, other software needs that too. Some enterprises use their own identity provider and I would prefer that as well. Usually that is probably some windows ldap database that can easily be integrated, but there are a lot of other solutions as well.
shouldn't every new company be using SSO for everything in 2025 and beyond? how long before this no longer becomes a good signal?
> but remember that the big price-insensitive customers pay for the price-sensitive customers
You mean they more than make up for the loss of those customers? What is the underlying cost on the service? Isn't the profit margin here absolutely absurd since the underlying cost to the vendor is basically zero once their implementation is written?
Yes - it's an enterprise versus SMB distinction that doesn't require asking questions like "What's your revenue?" in the qualification. Enterprises need it. SMBs don't.
This is how I've come to accept it too
And honestly when I really really want SSO anyways, I can bolt on vouch proxy for free
What are your normative views on this topic?
That there's nothing magic about security to exempt it from economics.
That's not a normative view (the hint is the "there's" which is a contraction of "there is"). A normative view would use the word should or ought.
Pretty sure I meant what I said.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Do you mean that you don't have a normative view on it, or that the thing you said was a normative view, or something else?
If you want to fit the word "should" in there somewhere, you can. I think SSO is important, and it would be one of the first 3 things I would stand up at any new shop I went to, but I can think of more important security things that nobody really thinks should be equally distributed across companies.
Okay:
"That there should be nothing magic about security to exempt it from economics."
I disagree quite strongly with this! I think a reasonable premium for SSO support costs is fine but severe price discrimination/bundling based on security features is unethical. That is because security issues have large externalities on uninvolved parties.
That's not the fault of the vendor, it's the fault of the customer who refuses to pay for what the vendor charges. You couldn't argue that it would be "unethical" for Atlassian to charge $1000/seat; you'd just say it was too expensive. Somehow though, when you bundle security into that, you don't look at it and say "customers should not use the cheap-o account type and should pay what Atlassian is actually charging for this service, or use a different provider" --- no, they blame Atlassian.
No, not valid. It's Atlassian's customer that's on the hook for securing their offerings to their customers. Atlassian is holding up its end of the bargain. If you don't like it, don't take them up on it! I don't!