An admittedly wandering defense of the SSO tax

As someone who deals with application support, another big reason is SSO is such a support nightmare. No one wanted to touch SSO tickets because of how frustrating they were to deal with. People wouldn't follow the instructions. Microsoft/Google moved something in their portal and we didn't know so instructions were useless. Microsoft/Google would be having issues and we got tickets because they were still working until tokens expired. Their Admins would turn on 2FA and when their support desk got "Cannot login to $OurProduct", they would just flip it over to us without caring. List goes on and on.

No problem at all with the concept of price discrimination. The economics make sense. In any scenario where unit costs are low, but development costs are high, the ideal situation is where everyone gets the benefit of having the product at a price they are willing to pay. Maximizes total value to all parties.

The problem with the SSO tax is that it wedges itself into the pre-existing cracks in most organizations. Security practitioners are already in conflict with other departments. What happens when a department head has pitched a new SaaS as being 1x price, but then it becomes 2x price after the security team's requirements are added? It is not seen as the [application is expensive], it seen as [security team's requirements have doubled the price]. Conversely a price discrimination strategy which locks specific user facing features behind a specific tiers means that the same person championing the software, would also advocate for the appropriate payment tier.

Price discrimination is a valid strategy. Responding to organizations who are actively making the security practitioners job more difficult is also valid.

This is a good economics lesson but fails to address the actual issue people have with the SSO tax. It isn't about the concept of price discrimination, but price discrimination when it comes to security. You can charge extra for convenience features or other value-add features, sure, but the choice of login provider is something that should be table stakes for every person and every organization regardless of how big they are or how much they can pay. An even worse example – plenty of apps gate two-factor auth behind a paid tier as well.

It's a bad system and you should feel bad for using it.

By all means charge enterprises more, but base it on something else, headcount, revenue, non-profit status...whatever.

Every time I hear about a data breach I wonder if someone avoided perfectly reasonable SSO protections because of this tax.

This car with no seat belts, no airbags, and no ABS is just price discrimination! Strangely, no one seems interested in celebrating the implied discount for not having safety.

My job involves working with customers to test out products - has for years, and for several jobs. None of my products have ever charged extra for SSO, and most require it, so I get to deal with it all the time.

For the past 5+ years, the part of configuration that takes the longest - by far - is always SSO. I cannot imagine the amount of added support calls, time, and frustration brought about by it, so I can completely understand why some companies gate it behind more expensive tiers.

I was responsible for IT in a hypergrowth scale-up and I don’t like this article, it misrepresents the problem. The problem is, when you are big enough to set up SSO like Okta, you have to upgrade nearly all of your subscriptions in a short time to make use of it, suddenly resulting in a huge increase in the budget. So, let’s say the business goes from X to 2X in revenue and from X to almost 2X in staff (let’s assume there’s some small increase in productivity over time). In some incredible logical twist every SaaS provider thinks that 2X increase in price is affordable, despite that the company is still burning money and the enterprise features aren’t really needed yet. 2X budget isn’t approved by CFO, cost-cutting exercise starts and price increase is matched by significant reduction in number of licenses. Did it worth it? Not sure. Volume-based pricing complimented by feature add-ons would do a good job too.

This argument is basically wrong because it supposes companies don't have market power when they do. "Market power" doesn't mean monopoly. It takes at least four and more often at least a dozen viable competitors before you have enough that there isn't an implicit cartel, and there are altogether too many markets where this is the case.

Nearly all specialty or line of business software, for example. These markets commonly have two or three providers and rarely have hundreds. Literally the intended purpose of copyright in this context is to give the authors market power.

And then the example given is the sympathetic one. The premise here is that there are the same number of customers willing to pay $40 as $10, and so the rational choice for a company not engaged in price discrimination is to charge $40 to everyone and price discrimination allows them to provide a "discount" to half of the customers.

Now suppose that only 10% of the customers would be willing to pay $40. The single-price profit-maximizing strategy is then to charge $10, because 100% x $10 is more than 10% x $40, and no customer benefits because all price discrimination does is allow them to overcharge the remaining 10%.

More to the point, in an actually competitive market, price discrimination isn't possible. If the marginal cost of providing the service is $7 and anyone is charging $40 to anyone, someone else could take those customers by charging $39, and someone else could take their customers by charging $25, until the market price is a thin margin over the underlying cost of providing the service. Because even the customers willing to pay $40 would prefer to pay $8, and the company that has 0.25% market share at $40 would rather have 10% market share at $8.

The better argument in favor of the "SSO tax" is the one from the comments: That SSO actually increases the cost of providing the service by raising support costs.

I don’t really mind paying for SSO. It’s fine. But I hate that it’s the one feature in the “enterprise” tier that I need, and now I have to talk to a sales rep and sign a contract. You could have just charged me more per seat and it would have been better for both of us. Instead I looked for another vendor that didn’t let their sales team convince them to let the AEs gatekeep a basic feature.

This argument misses the mark that SSO tax is charging extra for a practice that: (a) BnL everyone should do, (b) reduces the SaaS provider's liability, (c) is incredibly costly to change/transition how it's done after initial setup, (d) actually doesn't add much overhead when using poor-man's SSO aka OIDC/OAuth2* (the now ubiquitous "sign in with" or "continue with" buttons that require zero integration once set up once), (e) drags in a host of other odious interactions most buyers want nothing to do with (Call Us? Why?), and (f) is bad for industry trust as a whole.

Also, people wouldn't even mind if you added $2/user so you can't lose their creds and they don't have to remember your password. (For comparison, all of Microsoft E5 security tools together add ~$20 to M365.)

If you really want a differentiator they have to pay for that isn't SSO, go with "audit logs", "RBAC", and "Team Roles" management as lifts. Most anyone required to use SSO is required to use vendors that support audit logs. For SSO itself, you can also still charge for "automated group provisioning" (what used to be SCIM in SSO world). By the time they care about teams, they care about this.

See more features to charge for here: https://www.enterpriseready.io/

* This is on top of the argument from elsewhere in this thread, "Use our Google login then..." Note to the B2B startup bubble: more of your potential small, mid, and Fortune 500 business customers (where customer headcount > 1) can "Sign in with" Microsoft than Google. (Some estimates put it at 85%). Meanwhile, what startups and businesses on each side of B2B think they need legacy SSO/SAML for, most can actually meet all their requirements with this far more straightforward approach combined with a domain name control check and email domain filter.

This a terrible defence.

The reason there's a belief of an SSO tax is not that you have to pay more to get SSO, it's that companies use SSO to get you to pay for features no-one ever wanted but they did a lot of development on because they know you need SSO.

And the gatekeeping of it behind sales people.

Coming in late to this discussion but I take issue with people framing charging more for features as price discrimination. It's not, it's selling more features for more money.

This is the same way all airlines in the world work since the invention of Revenue/Yield Management. Which is basically price discrimination to get the biggest piece of the value.

Airlines will mostly segment client based on things like Minimum Stay (in destination) and how many days before the flight the ticket was bought to find the most desired of all users: The business traveler.

SSO is (roughly) the same thing, companies who would like SSO are probably the ones in the corporate level, and this is an efficient way to find them. Of course there are false positives, but software companies are willing to live with those to get the biggest part of the pie.

And this is actually good for users, as it allows for the other users who have more flexibility to pay a lot less (both at airlines and software) than they would pay if those companies didn't discriminate.

> Some of us believe that all parties should pay a fair price, the same price for a given product or service. I have some sympathy for that perspective. I myself have felt tempted to describe certain prices as ripoffs, saying something like “a bottle of water should not cost $8” while waiting to board a flight at SFO. It’s very natural for us to say things like that.

Airports are natural, government-administered monopolies, who then typically auction off the rights for firms to sell to a captive audience with little to no competition. This typically results in unfair and wasteful allocation of resources.

This reminds me of when several years ago I was a pretty early enterprise Vault user - I poc'd out a pretty simple implementation with the OSS version that at that time included SSO support with Okta. Management was like "great we don't have to pay for any of this then, let's use OSS then" and I argued that there was zero chance they were going to leave that as a OSS feature, sure enough, some months later they rug pulled it. It was pretty much the only additional feature outside of core functionality we absolutely "needed," everything else was pretty fluff.

It appears that many of the complaints in this thread are related to the complexities of SAML. I configure, manage, and troubleshoot many SSO configurations in my work but they are all OAuth2/OIDC based and find them really quite simple, easy to understand, and the RFC's a pleasure to read. Has anyone used both SAML and OIDC in their career and could comment on whether I avoided a difficult time in SSO with SAML, or am I just unaware of the difficulties because its what I regularly work with...

Implementing SSO is a nightmare, particularly if customers want controls on their side.

My view is that you should use Cognito (simple) or Auth0 (simple but expensive) and build a self-setup page for it. Then if customers want it, it's on them to deal with configuring.

Oh, and push them all to OpenID because it's a lot less hassle than SAML.

If you're selling to big businesses (and you generally want to be), they'll pay for it anyway because this sort of security thing falls under various box ticking exercises for ISO certifications.

> We can’t live in a world with zero profit. And who should determine what reasonable profits might be?

The society under whose umbrella we operate.

> a bottle of water should not cost $8” while waiting to board a flight at SFO. It’s very natural for us to say things like that.

The problem is the bottle of water is only worth $8 in part because they keep you from bringing in drinks not because its especially valuable at that time and place.

It's the difference between actually creating value and exploiting people out of their money

I can‘t help to observe that the shapes in the article can be sorted by color and shape, with each resulting stack being numbered from 1 to 4. Problem solved ;)

Nice explanation. I'd be interested in hearing from anyone who used to feel negatively about the "SSO tax" and then switched to feeling positive/neutral about it — what changed your mind and why? Vice versa, too. (Not interested in rehashing arguments about why it's good or bad.)

Coursera 12400% Increase is CRAZY

Neat advertisement to drum up support for easily adding SSO with an open source tooling.

The reality is much simpler than the article would have you believe. The article goes through all these convoluted explanations about value add but the simple fact of the matter is that SSO is the one differentiator that businesses will guarantee pay for. The other features are often unknown to stakeholders outside of the internal champion and need explanation oftentimes. But SSO, enterprises always need at a certain scale. So it’s incredibly effective because it’s the one feature that every single enterprise that wants to purchase your product cannot do without.

In fact, the exact opposite conclusion of the article is reached if we follow this logic. One of the taglines reads: Buyers want different things. Well, maybe the stakeholder/champion actually using your software might. But often they are not the ones that are making the money decision in an organization. The people who ARE making that decision, however, do not want different things. They probably could care less about different things. They want SSO.

I get that there's some correlation between hacker culture and piracy and free as in gratis.

But lately I've seen a flood of flat out complaining about things costing money.

As software devs we should be for software having a price tag, not against it