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.
SkyPuncher 148 days ago [-]
I was lead engineer for a startup. By virtue of being the most flexible in my day-to-day, I ran front line for most of the customer support issues.
SSO issues took exponentially longer than nearly every other support issue and accounted for well over 50% of our support efforts.
We didn’t really feel like there was much we could do about it either. Most of it came down to the fact that the user of our application was not the person also able to setup SSO. The result was a massive game of pass the hot potato until we would get fed up and request a call with our customers IT team.
doctorpangloss 147 days ago [-]
Yeah but does that require any expertise to solve? It’s a bunch of meaningless arcana, for which the other party pays well. Seems like a fair deal. Someday you might get big enough where it’s minions talking to minions, or so big that people simply accept no customer service as the status quo.
SkyPuncher 147 days ago [-]
It depends. I certainly wouldn’t say it’s approachable.
There are basically three major issues that require a bit of seniority to support:
* it’s an auth controlling system so mistakes can mean significant data breaches.
* there’s shared responsibility between provider and customer for configuration. Further, there are a lot of possible configurations to consider.
* the concept behind SSO is largely simple, but the implementation can be very complex. It’s almost always specific to your auth system and controls.
grinich 148 days ago [-]
The “human cost” of SSO is definitely the hardest part.
At WorkOS we solved this by shipping the whole config workflow in the form of an admin portal. It checks things like SAML certificate, signatures/assertions, attribute mapping, etc. and a zillion other edge cases across dozens of identity systems.
Yes! We don't charge for SSO, but thankfully we've only had our largest customers ask for it -- and every time it required significant back-and-forth to get it set up. Basically every time somebody comes in with a new IdP, I have to go stand up my own instance so I can figure out what weird combination of options will make it work, because I'm convinced nobody actually understands SAML.
seszett 147 days ago [-]
> I'm convinced nobody actually understands SAML.
That's my conclusion as well. We're a small shop and I used to feel a bit incompetent every time we'd setup SSO with a big client and it wouldn't work as it should, until I noticed that it was due to inconsistencies, misconfiguration, on their side more than half of the time.
Now I've accepted it though and I don't mind doing that part of my job. I know they feel somewhat incompetent on the other side as well.
I have to say, once it's setup it just works without any other intervention required though, I have very few support requests related to already existing SSO setups.
jiggawatts 147 days ago [-]
Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible.
PS: the single most common developer error is assuming the SAML configuration is static and has a single certificate somewhere. The modern approach is to get all configuration from a metadata XML file including the multiple overlapping certificates that are used to implement seamless rotation on a schedule. If you haven’t accounted for this, you’ve “made it work” just like a child making a flying machine by throwing a rock.
(Guess what I was troubleshooting just this morning in a vendor product juuuust this morning. I’m not bitter this is the fifteenth time I’ve seen this exact issue. I’m not!)
7bit 147 days ago [-]
> Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible.
I die Not make this experience. The specs exist and are detailled. I'm Not convinced your Last sentence ist true.
Even within the same profile, I've seen some major incompatibilities. For example, some Microsoft products interpret XML signing ever so slightly differently to many other libraries, breaking the protocol. (From what I could tell, MS was interpreting the standard correctly, others weren't, they were just testing against each other.)
The biggest gripe I have about SAML is that it's one of "those" committee-designed standards that has an inner-platform effect of using it's own custom extensibility model on top of the eXtensible Markup Language (XML). It's like the bad database schemas that have one table with three or four columns holding all data because the developers couldn't be bothered to learn SQL.
I was just troubleshooting SAML issues yesterday, and the library used for that is about 750 KB of compiled bytecode. The source must be over 2 MB, not including also heavyweight dependencies like XML, XML Schema, and XML Signing. For something as trivial as "send me a token with some attributes and a signature" it's way, waaaaay overcooked.
sparrish 148 days ago [-]
This is the real reason there's an SSO tax. It costs to support SSO, the customers who want SSO should pay for that cost.
ned_at_codomain 148 days ago [-]
I would agree that this cost-plus pricing structure applies in some cases. Some companies definitely want to constrain the universe of SSO users.
But this will usually show up in pricing structures with SSO as a relatively inexpensive add-on feature -- not as part of an indivisible bundle.
Seemingly we want to talk about both of these things as "the SSO tax" but I think we can agree that they're pretty different scenarios.
candiddevmike 148 days ago [-]
There are plenty of folks who setup SSO with open source projects without a support contract. Why should they have to pay for it with other software?
sethops1 148 days ago [-]
Because the engineers of the other software chose not to work for free?
candiddevmike 148 days ago [-]
I'm not saying they shouldn't be compensated, just that justifying the SSO tax due to the support burden is pearl clutching.
antimemetics 147 days ago [-]
Do you mean that the support burden is not a valid reason to charge for SSO?
In my experience support us the most tedious, annoying, and time-costly part of building a SaaS so I would definitely always charge extra for anything that requires more support
fomine3 147 days ago [-]
all functionalities are absolutely no warranty
wmf 148 days ago [-]
I thought some company had free SSO for Google and 365 only and advanced SSO on the enterprise tier. I don't remember which company though, so maybe I made this up.
chgs 147 days ago [-]
There’s a cost to support non sso authentication to.
sparrish 147 days ago [-]
non-sso authentication isn't nearly as support intensive. Sure there are support requests for 'regular' authentication but it's usually the "I can't remember my email" or "I can't remember my password" type stuff - easy replies.
SSO issues usually takes 10 or 20 times longer to sort out any issue.
t0mas88 148 days ago [-]
This it's exactly the issue with SSO and enterprise customers with complex requirements on how their IDP needs to be integrated.
wkat4242 147 days ago [-]
Meh. Most of them are using off the shelf stuff like Entra ID or Okta. They support complex configs but it's all on the side of the IDP. For the end service it's just SAML.
crote 147 days ago [-]
That's why you charge extra for the White Glove Service turnkey support tier. Nobody's claiming every SaaS vendor has to spend days of support time handholding every single customer through setting up semi-custom SSO solutions - we're all just asking for the vendors to stop gatekeeping the basic off-the-shelf SSO implementation!
johngalt 148 days ago [-]
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.
paxys 148 days ago [-]
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.
SOLAR_FIELDS 148 days ago [-]
Sure, but most SaaS support “SSO at home” in lower tiers via either Google idp or GitHub. So yes you’re locked into those vendors which kind of sucks but it’s not necessarily true that you have to give up security without forking over the “SSO tax”
mynameisvlad 147 days ago [-]
I mean, no. If they supported BYOSSO then they wouldn’t be, by definition, charging an SSO tax. People are using the term when SSO as a concept is gated behind a paywall.
SoftTalker 147 days ago [-]
A customer who wants SSO is signaling that they are using this product in their business operations. I.e. they are making money from it. They aren't just learning it, or using it as a hobby. Therefore the product vendor is going to charge the customer at least some approximation of the value the customer is gaining from the product.
aaronfitz 137 days ago [-]
While generally true it's not a perfect signal. I would love to roll out SSO for my family off of my domain but can't because of the SSO tax. I realize power users like me are in the extreme minority
e_y_ 147 days ago [-]
The amount of money and budget that a company has can vary wildly. Just because your company uses SSO doesn't mean you're a Fortune 500.
Of course this mostly means that if your required feature set falls into the "Contact us for pricing" tier then you're going to have to talk to a sales rep (probably several, from different vendors so you have a competitive quote) instead of getting any kind transparent pricing.
tptacek 148 days ago [-]
There's no moral valence to price discrimination on enterprise security features.
wolrah 147 days ago [-]
Exactly my thoughts. IMO it's analogous to SSL/TLS, which for the longest time was something you had to pay extra for at multiple levels. You had to get a dedicated IP for your service instead of being able to use shared hosting, you had to buy the certificate itself, and you had to have someone renew it and install the new certificate every now and then. Even from the user side there were web sites I remember where SSL access as a client was a premium feature as if it had a meaningful cost per use instead of just the cost to have it available at all.
This was long lamented in the security-focused parts of the internet but no significant movement happened until late 2010 when the Firesheep extension made sniffing unencrypted passwords or session keys accessible to the masses. Suddenly it wasn't just security nerds complaining about things that could easily be brushed off by higher-ups, it was a problem that anyone who could install a Firefox extension (which thanks to ad blocking and the general badness of could see with their own eyes
Almost overnight major services decided that they in fact were fully capable of offering encrypted services to everyone. Suddenly client and server applications, SSL/TLS libraries, etc. that had been ignoring SNI all started supporting it over the next year or two so you didn't need a dedicated IP per hostname anymore. The ISRG was formed and developed Let's Encrypt to solve the problem of having to pay for certs, and while they were at it took the opportunity to develop and enforce the use of ACME with short-lived certificates so automation was effectively mandatory.
In six years we went from there being a "SSL/TLS Tax", which every part of the process would defend as absolutely necessary costs, to it being freely available to all and automatically supported by a lot of major application and service platforms.
I look at the SSO Tax situation as being mostly comparable from the user side of things. The internet as a whole would benefit from wide support for SSO, but the demand to solve the problem is minimal because most of the people making the purchasing decisions don't care about the problem enough to make it a requirement.
There are definitely some valid points that have been made about support costs associated with SSO, especially with regards to supporting more than just a couple of big name identity providers, but I don't think most people would complain if a vendor limited their free/cheap tiers to those couple of big systems those clients are likely already using. If someone needs custom integration they get to pay enterprise prices, but if they just want to sign in with Google that should be accessible to all. The support costs should scale well with a good implementation, hypothetically if Google or Microsoft changes something that breaks your integration you only have to fix it once to solve issues for everyone using it, as opposed to private identity services where each tenant might need something slightly different.
anotherhue 148 days ago [-]
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.
throw10920 148 days ago [-]
> It's a bad system and you should feel bad for using it.
What "system" is bad and why? The poster made several arguments - which one of them are you rebutting?
The core idea that "you should have to pay more money for more features" makes sense from a basic economics standpoint (regardless of other rationalizations).
> I wonder if someone avoided perfectly reasonable SSO protections because of this tax
I don't know how much sense this speculation makes. SSO is complex to set up - without data, you could just as easily argue that misconfigured SSO makes breaches more likely, instead of less.
Plus, from a more practical standpoint, if you're frustrated about the never-ending stream of breaches (as I am), then it'd be better to push for laws that make the end result (personal data leaked) directly illegal with steep fines. There's too many different "upstream" problems (lack of SSO, default database credentials, buffer overflow in web application, misconfigured authorization system in webapp, etc.) for the strategy of "wage war against them one at a time" to be productive.
148 days ago [-]
colechristensen 148 days ago [-]
If you have enterprise pricing, have substantial enterprise features. That’s it.
wmf 148 days ago [-]
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.
ned_at_codomain 148 days ago [-]
This is a solid objection that I hadn't considered before!
Why isn't SAML SSO mandated (either literally or my convention)?
Practically speaking, as someone who spends all day trying to convince developers to implement SAML SSO, I really wish this were the case :)
I think in practice, software vendors correctly assess that relatively few of their prospective customers actually care.
If many small / price sensitive companies really wanted SAML SSO from their vendors -- if there were really meaningful demand -- I imagine we'd see more pricing plans with SAML SSO bundled into entry level tiers.
As for mandates, this is a challenging ethical question. I don't think it's necessarily obvious in all cases that some institution should impose safety regulations upon us.
There's clearly some set of risks we accept, and some set of risks we don't accept. And we all draw the line in different places.
This is pretty obviously true. Not many of us worry about objects randomly falling off buildings. We don't all wear helmets all the time. It's certainly a risk, but do we really care?
I think the revealed preference from many software buyers is basically ... no, they don't care about having the security benefits of SSO.
commandar 148 days ago [-]
>This is a solid objection that I hadn't considered before!
To be quite frank: this strongly suggests that while you put a lot of effort into writing a long article in defense of the SSO tax, you didn't perform more than the most cursory research about why it's a topic of discussion.
This argument is literally above the fold on the two top search results for the term.
>In short: SSO is a core security requirement for any company with more than five employees.
And the other explicitly makes the car-safety analogy:
>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power. Not offering security features if they already exist in your product means a vendor doesn’t care about your security. Our aim is to spotlight vendors who overcharge for security features, in hopes of instigating a change in the industry.
And to be franker: the word "security" appears exactly once in your entire piece. That's a near-complete avoidance of the actual issue that people are highlighting.
I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
ned_at_codomain 148 days ago [-]
Hm, that seems like a misrepresentation of what I'm saying.
I specifically meant that the previous commenter made me think of mandates.
I run a company that makes SAML SSO software. I've thought quite extensively about SAML SSO. See:
Addendum: I have a very strongly vested interest in more people using SSO. I literally spend my time trying to convince developers to set it up!
throw10920 148 days ago [-]
>>In short: SSO is a core security requirement for any company with more than five employees.
This is from a random website with no credentials that makes no arguments to back up its claim. It's meaningless.
>>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power.
And this is a fatally flawed analogy that renders it useless. The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Neither of these quotes support this position.
> The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer.
As to this - is there any actual empirical evidence that missing SSO meaningfully weakens security for small businesses, which are the ones that would actually care about forking over the extra for the enterprise tier? That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage. I find it unlikely that missing SSO matters that much from them, and I'd like to see empirical evidence otherwise.
Also, there's nothing wrong for charging different amounts for different levels of security, assuming that that cost translates into actual effort (which it does for SSO). Normal people pay small amounts of money for physical door locks that are woefully insecure - the proposition that lock manufacturers should make their industrial and home locks cost the same would be pretty ludicrous.
commandar 148 days ago [-]
>This is from a random website with no credentials that makes no arguments to back up its claim. It's meaningless.
Appeal to authority. Meaningless.
All I was pointing out with those links is that literally Googling the term "SSO tax" and clicking the first link at least hints at some of the reasoning behind people making an issue of this. The fact that TFA doesn't address any of the actual concerns people have in any meaningful way makes it of incredibly limited usefulness in the overall discussion.
> The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Then charge for the support. The issue is that the only way to purchase a core security feature is bundled in with other features that the user doesn't necessarily want or need, very often at several multiples of the price for the features they do want.
>That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage.
This is working from the faulty assumption that potential customers only exist in a binary between the nebulous "enterprise" and "small business with barely any IT competency."
I live in the enterprise healthcare world. It's routine for us to consider software purchases at the departmental level to fill a specific need for a particular team. We have hard requirements for SSO. Some of it's driven by internal policy, some of it's driven by auditors increasingly demanding MFA everywhere.
I have personally killed deals over this exact issue on a more routine basis than I'd like. Department head thinks cost is going to be Y. Cost is actually 5-10Y because the only way to purchase SSO support is via an "enterprise" bundle with additional features they don't need and an inflated minimum seat-count buy. We'd happily pay some middle ground for SSO support, but the option to buy it doesn't exist.
The issue is not charging for things that have support costs; it's forcing a customer into drastically higher pricing tiers under the assumption that running SSO is a signal that a potential customer has a super sophisticated environment and bottomless pockets. That was the world of 15 years ago, sure, but it's not today.
The reality is we live in a world where there are increasingly strict security requirements in many industries and any business paying, e.g., $6/user/month for Microsoft 365 has SSO available as an option.
statictype 147 days ago [-]
>I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
I made this comment the last time the SSO Tax question came up: We routinely deploy our platform to large customers for 6 or 7 figure contracts.
The number of them who actually deployed SSO (without just asking if we comply with it) is less than 20%.
commandar 147 days ago [-]
FWIW, I've mentioned elsewhere in the thread, but I'm in healthcare. SSO (and MFA) have only really become hot topics in the past 5 years or so.
In the past? People with enough weight would absolutely blow right past implementing SSO if it was slowing them down or adding to their cost.
These days it's a hard requirement for us: if it's not SSO it doesn't go into the environment. That's becoming the norm across the industry.
This is one of those very, very rare cases where healthcare is probably ahead of the curve relative to a lot of other industries. Consequence of being highly targeted by attacks and insurers starting to get very particular about how the ship is run.
ameliaquining 148 days ago [-]
On a lot of issues (passwords, SQL injection, automated deployments), buyers originally didn't care much about security, but the security community slowly but surely managed to shift norms and get doing the right thing to become normalized. I think that could happen on SSO too, if not for the fact that it's so effective as a price discriminator, which in turn I think makes it less likely to happen absent some kind of regulation. (Developers at small companies might not care, or they might want to do the right thing but be unable to justify it to the boss; meanwhile, SSO is usually a non-negotiable requirement for enterprises. I think that's a bigger factor than apathy or "price sensitivity" (enterprises are often extremely price-sensitive) in why it's such a good discriminator.)
I favor regulation on this, even though it's probably not necessary in every case, simply because I don't see any other way to break this equilibrium.
chgs 147 days ago [-]
> Why isn't SAML SSO mandated (either literally or my convention)?
I used OIDC for my internal sites to integrate with our corporate SSO provider. Why would I need to use saml instead?
wmf 148 days ago [-]
I also don't want to mandate anything but as an industry we have to find some way to do better on security. Free SSO and 2FA with very strong nudges seems like a good path.
DaiPlusPlus 148 days ago [-]
> Why isn't SAML SSO mandated
SAML isn't exactly the best choice here. It's very SOAP-y; that's like being in 2005 and mandating everyone use SOAP+RPC for interopability.
148 days ago [-]
tptacek 148 days ago [-]
It is in fact reasonable to charge more for vehicles suitable for commercial fleets and applications than for commuter vehicles.
google234123 147 days ago [-]
Wasn't it true that for a long time that cheaper cars were just less safe than more expensive cars?
wmf 147 days ago [-]
That probably was true... and then we raised the baseline.
abigail95 147 days ago [-]
People today will still buy used cars without those features. You would force them to pay more? What if they can't?
I wouldn't celebrate taking those cars away from people.
michaelmrose 147 days ago [-]
We effectively did tell them they can't by not allowing any vendors to ship a lower cost car without those features. This method of operation in the car industry is incredibly common and has probably saved hundreds of thousands of lives.
As far as the older cars without those features allowing them to age out has almost entirely worked.
crote 147 days ago [-]
This car comes with a spike pointing out of the steering wheel. For a premium fee we'll replace the spike with an airbag. Why aren't you cheering for the cost-saving spike-flavored steering wheel?
happyopossum 148 days ago [-]
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.
ivan_gammel 148 days ago [-]
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.
danenania 147 days ago [-]
Let’s not forget that the whole reason your company needs to upgrade all its subscriptions for SSO is so it can get a soc2 and offer its own high-priced enterprise plan (which is probably gated by SSO).
ivan_gammel 147 days ago [-]
Do you realize there exist other types of businesses?
AnthonyMouse 148 days ago [-]
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.
ned_at_codomain 148 days ago [-]
I can identify basically three criticisms of my argument in your post.
(1) That I assume companies never have market power.
(2) That I suppose "market power" implies monopoly
(3) That my example was cherry-picked.
1. I did no such thing. I explicitly acknowledged market power several times.
2. Again, not correct. I explicitly mentioned oligopoly (assuming that 'imperfect competition' wouldn't land).
3. Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
Your own comment claims that "actually competitive" markets can't have price discrimination. Sure, we can suppose the law of one price applies to perfectly competitive markets, but there's no sense in which a perfectly competitive markets "actually" exist at all! The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
My appeal to the airline industry as an example was not an accident. There's a very well-established literature on the relationship between competition and discrimination in the airline business. It's *certainly* not a settled question that discrimination decreases as competition intensifies. I included a classic from Stavins below that finds precisely the opposite of your claim.
My argument here isn't perfect. I can think of many flaws, many reasonable objections. But I don't think you're using any of them here.
> I did no such thing. I explicitly acknowledged market power several times.
Your premise is that if market power exists then market power is the problem rather than price discrimination. The issue is that price discrimination isn't possible without market power. Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier.
> That I suppose "market power" implies monopoly
This is not an argument you make explicitly, but it's something readers commonly assume and my point is to highlight that companies successfully engaged in price discrimination can and do have market power even if they don't have a full monopoly.
> Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
And I'm providing the 'there exists' claim for the alternative, to demonstrate that price discrimination can be (and often is) detrimental to customers without providing any countervailing benefit to any of them.
> The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
Profit doesn't really work that way. For example, if a company takes investment and uses it to buy a building to operate out of, the money not paid as rent to a landlord is added to the investor's profit, but if the company takes less investment and instead pays rent, the same money is counted as operating costs. Likewise, if you develop software needed before you can start operating and you take investment to pay for it, the net returns are called profit, but if you take a bank loan to pay for it then the interest on the loan is counted as operating costs again. The interest rate you'd pay the bank would even be proportional to the risk you'd fail, unless you post collateral, for which you'd need an investor.
So a company that didn't take any investment and operated entirely by renting everything, taking loans and using off-the-shelf software instead of developing anything in-house wouldn't be expected to make any profits in a perfectly competitive market -- and there would also be no investors to pay any profits to. Profit in companies that take investment would still be present and equal the cost (time value) of the assets bought with the money, but in a perfectly competitive market this would exactly equal the risk-adjusted market rate of return in the overall capital markets.
The distinction in uncompetitive markets is that profit exceeds that amount. (Or at least can; a market can be uncompetitive and then the companies become inefficient from lack of competitive pressure and waste the money they extract from customers instead of returning it to investors.)
It's true that "perfectly" competitive markets don't exist in the same sense that perfect anything doesn't exist, but this is splitting hairs. A gold coin might be .999 gold and you can say that it isn't perfect but you can still distinguish it from a wooden nickel.
timv 147 days ago [-]
Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier.
"Overcharging" is a concept without a precise meaning. The SSO-capable version has a feature that cost money to build and support. That it is sold at a higher price (often alongside other enterprise features that cost money to build and support) is not proof that they are overcharging.
Any company that is tying to recoup the costs of building those features will charge the customers that use those features. The existence of a price differential between the 2 editions does not tell you whether they are overcharging.
AnthonyMouse 147 days ago [-]
> The SSO-capable version has a feature that cost money to build and support. That it is sold at a higher price (often alongside other enterprise features that cost money to build and support) is not proof that they are overcharging.
"Price discrimination" is charging a higher price to one set of customers than another. The premise is that they're really getting the same thing but one of them has to pay more in exchange for either nothing or for something whose incremental underlying cost is far less than the incremental price increase, because the company devised a way to artificially segment the market.
If your argument is that the extra feature would actually cost that much even in a highly competitive market because it costs that much more to provide it, what you're really arguing is that they're not engaged in price discrimination.
icambron 148 days ago [-]
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.
Terretta 148 days ago [-]
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.
* 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.
philipwhiuk 148 days ago [-]
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.
happyopossum 148 days ago [-]
> features no-one ever wanted but they did a lot of development on because they know you need SSO.
I’ve been around product development for 20+ years and I have NEVER seen a feature that “no-one ever wanted” get a lot of development resources.
What I see a lot are features that a few huge customers want get those resources, and other people without that perspective write them off as useless. Meanwhile we’re closing 9 figure deals on the backs of those “useless” features.
rpigab 145 days ago [-]
Ad placement in software? Not many users appreciate it, and usually it's implemented to create value for the software company, not for the user. And yet it usually gets a lot of development resources.
abigail95 147 days ago [-]
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.
dakial1 148 days ago [-]
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.
jessriedel 147 days ago [-]
> 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.
JohnMakin 148 days ago [-]
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.
carus 146 days ago [-]
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...
physicsguy 147 days ago [-]
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.
michaelmrose 147 days ago [-]
> 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
phkx 147 days ago [-]
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 ;)
matheist 148 days ago [-]
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.)
148 days ago [-]
Woshiwuja 147 days ago [-]
Coursera 12400% Increase is CRAZY
tomrod 148 days ago [-]
Neat advertisement to drum up support for easily adding SSO with an open source tooling.
SOLAR_FIELDS 148 days ago [-]
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.
commandar 148 days ago [-]
I'm in the healthcare world.
SSO is a hard requirement for us.
There have been many, many times where we've considered an application where we could justify the spend at, e.g., the departmental level for the limited user base that needed it, but where SSO being bundled into higher price tiers combined with minimum user counts took a potential solution from "very easy discretionary spend" to "not happening, full stop."
I'm often the one having to make these decisions. It's absolutely exhausting having to explain to non-technical department heads that "yes, this would solve your problem at a price that fits budget, but the vendor bundles a vital security feature into a tier that inflates the price to a point that it makes this unfeasible."
SOLAR_FIELDS 148 days ago [-]
Curious: Are SaaS sales unrepentant on pricing in these cases? I would think with a bit of spice on your side in procurement you could probably negotiate enterprise for a small premium over the middle tier. Knowing enough software sales people when given the choice between “Teams + $5/user/head” and “no sale at all” suddenly options open up. But maybe the people I know don’t support too much SSO stuff…
commandar 147 days ago [-]
Mixed bag, IME. Some vendors will work with you, some stick to their guns.
Either way, it's a surefire way for a potential vendor to automatically get lower priority from me as a potential buyer. Needing to haggle over what is, for us, a baseline security feature starts things off on the wrong foot.
karlgkk 148 days ago [-]
I think the friction here is from midsized companies. Where onboarding software that’s purchased is much harder than free software.
I think it might be worth saying “SSO is free, up to n users”.
Also this is pricing for “adequate security”, which rubs a lot of people the wrong way.
But I do agree, competent, organizational wide SSO with SCIM is definitely an enterprise feature.
SOLAR_FIELDS 148 days ago [-]
As I pointed out in a sibling thread, most SaaS offer “SSO at home” eg oauth2/oidc via either Google idp or GitHub in lower tiers, often in free tiers. So to get “adequate security” you don’t necessarily have to pay the SSO tax, but your alternative is that you must be locked to one of those two vendors, which is of course not ideal at all. But to say you have to pay the SSO tax to get “adequate security” is not really true at face value because of this.
That being said, obviously this situation as described sucks and we should not move towards it because really all it does is push SaaS startups towards these two vendors to punt huge licensing fees down the road until they have the revenue to support it. And by then they are significantly locked in to these specific two vendors, two vendors that already have problematic approaches to monopolizing certain things. So fixing this is important but for a different reason than one might take at face value.
TZubiri 148 days ago [-]
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
langcss 148 days ago [-]
The complaint isn't about anything costing money. It is about making SSO an enterprise feature which pushes the price up alot. At the same time SSO is good for security. So it is like an office space charging double for swipe cards instead of a number lock.
I think what annoys people is the reason why: a way to make more money from enterprises, and that they could make that money some other way.
happyopossum 148 days ago [-]
> So it is like an office space charging double for swipe cards instead of a number lock.
If the landlord had to hire a bunch of extra support people, with expertise outside their normal domain, just to support swipe cards then this would make sense, no?
I can imagine a lot of products where accompany literally could not afford to provide support for SSO issues to a basic tier customer with 100 employees
langcss 148 days ago [-]
Not really. Especially if both systems are already in place and they just need to turn it on.
The swipe system should be a very minor or zero part of the rent, not double.
happyopossum 148 days ago [-]
That’s never the case though - you don’t just “turn on” SAML integration. It’s a huge support burden, with every SAML provider requiring unique (and frequently updated) documentation, testing, and support enablement.
And that’s assuming you don’t include auth in any of your release testing cycles (which you should). If you do, now you’re including unit and end to end testing with Okta, MS, Google, OneLogin, Jumpcloud, Ping, and anyone else your customers choose to use.
Don’t forget to run those tests with both SAML and OIDC. And make sure the engineers who know how to co figure each of those vendors’ SSO systems are aligned with your testing schedules.
Also don’t forget that you need dev/partner accounts with all of those vendors. And they’ll need to be active when you test.
throw10920 148 days ago [-]
> Not really. Especially if both systems are already in place and they just need to turn it on.
This isn't a valid analogy to SSO. SSO doesn't just cost extra to develop (which in itself is a valid reason for charging more), but it costs extra to maintain - you can find several other comments in this thread alone talking about how difficult it is to support SSO from a technical/customer service perspective. People are expensive - both when writing code, and when supporting it.
langcss 147 days ago [-]
This is the same for all features no?
If customers need additional human support for SSO then that can be charged separately.
In my experience most customers can get it working with no hassles or have hassle but their own tech resources figure it out. Few need to get support.
As a feature it is probably less work to implement and maintain than the simplest of product features.
YMMV if you have a complicated integration but if you just want to sign people in and assign them to a group for security it isn't hard.
Maybe we are talking cross purposes? I am talking about SSO with SAML and IdP rather than OAuth.
I suspect the reason for the SSO Tax is it is an predictor of "does this customer have money". Customers with more money to spend and absolutely need SSO to meet their policies will overlap alot.
throw10920 147 days ago [-]
> If customers need additional human support for SSO then that can be charged separately.
Aren't the majority of enterprise contracts negotiated with support included? I thought that that was one of the main value adds for medium-to-larged sized companies.
langcss 147 days ago [-]
I think so. Even more reason to not need SSO tax ;-)
SSO issues took exponentially longer than nearly every other support issue and accounted for well over 50% of our support efforts.
We didn’t really feel like there was much we could do about it either. Most of it came down to the fact that the user of our application was not the person also able to setup SSO. The result was a massive game of pass the hot potato until we would get fed up and request a call with our customers IT team.
There are basically three major issues that require a bit of seniority to support:
* it’s an auth controlling system so mistakes can mean significant data breaches.
* there’s shared responsibility between provider and customer for configuration. Further, there are a lot of possible configurations to consider.
* the concept behind SSO is largely simple, but the implementation can be very complex. It’s almost always specific to your auth system and controls.
At WorkOS we solved this by shipping the whole config workflow in the form of an admin portal. It checks things like SAML certificate, signatures/assertions, attribute mapping, etc. and a zillion other edge cases across dozens of identity systems.
It’s pretty much “Stripe Checkout" for setting up SAML. Live demo here (click “Configure”) https://explore.workos.com/app/settings
That's my conclusion as well. We're a small shop and I used to feel a bit incompetent every time we'd setup SSO with a big client and it wouldn't work as it should, until I noticed that it was due to inconsistencies, misconfiguration, on their side more than half of the time.
Now I've accepted it though and I don't mind doing that part of my job. I know they feel somewhat incompetent on the other side as well.
I have to say, once it's setup it just works without any other intervention required though, I have very few support requests related to already existing SSO setups.
PS: the single most common developer error is assuming the SAML configuration is static and has a single certificate somewhere. The modern approach is to get all configuration from a metadata XML file including the multiple overlapping certificates that are used to implement seamless rotation on a schedule. If you haven’t accounted for this, you’ve “made it work” just like a child making a flying machine by throwing a rock.
(Guess what I was troubleshooting just this morning in a vendor product juuuust this morning. I’m not bitter this is the fifteenth time I’ve seen this exact issue. I’m not!)
I die Not make this experience. The specs exist and are detailled. I'm Not convinced your Last sentence ist true.
Even within the same profile, I've seen some major incompatibilities. For example, some Microsoft products interpret XML signing ever so slightly differently to many other libraries, breaking the protocol. (From what I could tell, MS was interpreting the standard correctly, others weren't, they were just testing against each other.)
The biggest gripe I have about SAML is that it's one of "those" committee-designed standards that has an inner-platform effect of using it's own custom extensibility model on top of the eXtensible Markup Language (XML). It's like the bad database schemas that have one table with three or four columns holding all data because the developers couldn't be bothered to learn SQL.
So instead of just this:
You have this monstrosity: I was just troubleshooting SAML issues yesterday, and the library used for that is about 750 KB of compiled bytecode. The source must be over 2 MB, not including also heavyweight dependencies like XML, XML Schema, and XML Signing. For something as trivial as "send me a token with some attributes and a signature" it's way, waaaaay overcooked.But this will usually show up in pricing structures with SSO as a relatively inexpensive add-on feature -- not as part of an indivisible bundle.
Seemingly we want to talk about both of these things as "the SSO tax" but I think we can agree that they're pretty different scenarios.
SSO issues usually takes 10 or 20 times longer to sort out any issue.
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.
Of course this mostly means that if your required feature set falls into the "Contact us for pricing" tier then you're going to have to talk to a sales rep (probably several, from different vendors so you have a competitive quote) instead of getting any kind transparent pricing.
This was long lamented in the security-focused parts of the internet but no significant movement happened until late 2010 when the Firesheep extension made sniffing unencrypted passwords or session keys accessible to the masses. Suddenly it wasn't just security nerds complaining about things that could easily be brushed off by higher-ups, it was a problem that anyone who could install a Firefox extension (which thanks to ad blocking and the general badness of could see with their own eyes
Almost overnight major services decided that they in fact were fully capable of offering encrypted services to everyone. Suddenly client and server applications, SSL/TLS libraries, etc. that had been ignoring SNI all started supporting it over the next year or two so you didn't need a dedicated IP per hostname anymore. The ISRG was formed and developed Let's Encrypt to solve the problem of having to pay for certs, and while they were at it took the opportunity to develop and enforce the use of ACME with short-lived certificates so automation was effectively mandatory.
In six years we went from there being a "SSL/TLS Tax", which every part of the process would defend as absolutely necessary costs, to it being freely available to all and automatically supported by a lot of major application and service platforms.
I look at the SSO Tax situation as being mostly comparable from the user side of things. The internet as a whole would benefit from wide support for SSO, but the demand to solve the problem is minimal because most of the people making the purchasing decisions don't care about the problem enough to make it a requirement.
There are definitely some valid points that have been made about support costs associated with SSO, especially with regards to supporting more than just a couple of big name identity providers, but I don't think most people would complain if a vendor limited their free/cheap tiers to those couple of big systems those clients are likely already using. If someone needs custom integration they get to pay enterprise prices, but if they just want to sign in with Google that should be accessible to all. The support costs should scale well with a good implementation, hypothetically if Google or Microsoft changes something that breaks your integration you only have to fix it once to solve issues for everyone using it, as opposed to private identity services where each tenant might need something slightly different.
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.
What "system" is bad and why? The poster made several arguments - which one of them are you rebutting?
The core idea that "you should have to pay more money for more features" makes sense from a basic economics standpoint (regardless of other rationalizations).
> I wonder if someone avoided perfectly reasonable SSO protections because of this tax
I don't know how much sense this speculation makes. SSO is complex to set up - without data, you could just as easily argue that misconfigured SSO makes breaches more likely, instead of less.
Plus, from a more practical standpoint, if you're frustrated about the never-ending stream of breaches (as I am), then it'd be better to push for laws that make the end result (personal data leaked) directly illegal with steep fines. There's too many different "upstream" problems (lack of SSO, default database credentials, buffer overflow in web application, misconfigured authorization system in webapp, etc.) for the strategy of "wage war against them one at a time" to be productive.
Why isn't SAML SSO mandated (either literally or my convention)?
Practically speaking, as someone who spends all day trying to convince developers to implement SAML SSO, I really wish this were the case :)
I think in practice, software vendors correctly assess that relatively few of their prospective customers actually care.
If many small / price sensitive companies really wanted SAML SSO from their vendors -- if there were really meaningful demand -- I imagine we'd see more pricing plans with SAML SSO bundled into entry level tiers.
As for mandates, this is a challenging ethical question. I don't think it's necessarily obvious in all cases that some institution should impose safety regulations upon us.
There's clearly some set of risks we accept, and some set of risks we don't accept. And we all draw the line in different places.
This is pretty obviously true. Not many of us worry about objects randomly falling off buildings. We don't all wear helmets all the time. It's certainly a risk, but do we really care?
I think the revealed preference from many software buyers is basically ... no, they don't care about having the security benefits of SSO.
To be quite frank: this strongly suggests that while you put a lot of effort into writing a long article in defense of the SSO tax, you didn't perform more than the most cursory research about why it's a topic of discussion.
This argument is literally above the fold on the two top search results for the term.
>In short: SSO is a core security requirement for any company with more than five employees.
https://sso.tax/
And the other explicitly makes the car-safety analogy:
>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power. Not offering security features if they already exist in your product means a vendor doesn’t care about your security. Our aim is to spotlight vendors who overcharge for security features, in hopes of instigating a change in the industry.
https://ssotax.org/
And to be franker: the word "security" appears exactly once in your entire piece. That's a near-complete avoidance of the actual issue that people are highlighting.
I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
I specifically meant that the previous commenter made me think of mandates.
I run a company that makes SAML SSO software. I've thought quite extensively about SAML SSO. See:
https://news.ycombinator.com/item?id=41036982
Addendum: I have a very strongly vested interest in more people using SSO. I literally spend my time trying to convince developers to set it up!
This is from a random website with no credentials that makes no arguments to back up its claim. It's meaningless.
>>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power.
And this is a fatally flawed analogy that renders it useless. The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Neither of these quotes support this position.
> The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer.
As to this - is there any actual empirical evidence that missing SSO meaningfully weakens security for small businesses, which are the ones that would actually care about forking over the extra for the enterprise tier? That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage. I find it unlikely that missing SSO matters that much from them, and I'd like to see empirical evidence otherwise.
Also, there's nothing wrong for charging different amounts for different levels of security, assuming that that cost translates into actual effort (which it does for SSO). Normal people pay small amounts of money for physical door locks that are woefully insecure - the proposition that lock manufacturers should make their industrial and home locks cost the same would be pretty ludicrous.
Appeal to authority. Meaningless.
All I was pointing out with those links is that literally Googling the term "SSO tax" and clicking the first link at least hints at some of the reasoning behind people making an issue of this. The fact that TFA doesn't address any of the actual concerns people have in any meaningful way makes it of incredibly limited usefulness in the overall discussion.
> The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Then charge for the support. The issue is that the only way to purchase a core security feature is bundled in with other features that the user doesn't necessarily want or need, very often at several multiples of the price for the features they do want.
>That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage.
This is working from the faulty assumption that potential customers only exist in a binary between the nebulous "enterprise" and "small business with barely any IT competency."
I live in the enterprise healthcare world. It's routine for us to consider software purchases at the departmental level to fill a specific need for a particular team. We have hard requirements for SSO. Some of it's driven by internal policy, some of it's driven by auditors increasingly demanding MFA everywhere.
I have personally killed deals over this exact issue on a more routine basis than I'd like. Department head thinks cost is going to be Y. Cost is actually 5-10Y because the only way to purchase SSO support is via an "enterprise" bundle with additional features they don't need and an inflated minimum seat-count buy. We'd happily pay some middle ground for SSO support, but the option to buy it doesn't exist.
The issue is not charging for things that have support costs; it's forcing a customer into drastically higher pricing tiers under the assumption that running SSO is a signal that a potential customer has a super sophisticated environment and bottomless pockets. That was the world of 15 years ago, sure, but it's not today.
The reality is we live in a world where there are increasingly strict security requirements in many industries and any business paying, e.g., $6/user/month for Microsoft 365 has SSO available as an option.
I made this comment the last time the SSO Tax question came up: We routinely deploy our platform to large customers for 6 or 7 figure contracts. The number of them who actually deployed SSO (without just asking if we comply with it) is less than 20%.
In the past? People with enough weight would absolutely blow right past implementing SSO if it was slowing them down or adding to their cost.
These days it's a hard requirement for us: if it's not SSO it doesn't go into the environment. That's becoming the norm across the industry.
This is one of those very, very rare cases where healthcare is probably ahead of the curve relative to a lot of other industries. Consequence of being highly targeted by attacks and insurers starting to get very particular about how the ship is run.
I favor regulation on this, even though it's probably not necessary in every case, simply because I don't see any other way to break this equilibrium.
I used OIDC for my internal sites to integrate with our corporate SSO provider. Why would I need to use saml instead?
SAML isn't exactly the best choice here. It's very SOAP-y; that's like being in 2005 and mandating everyone use SOAP+RPC for interopability.
I wouldn't celebrate taking those cars away from people.
As far as the older cars without those features allowing them to age out has almost entirely worked.
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.
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.
(1) That I assume companies never have market power.
(2) That I suppose "market power" implies monopoly
(3) That my example was cherry-picked.
1. I did no such thing. I explicitly acknowledged market power several times.
2. Again, not correct. I explicitly mentioned oligopoly (assuming that 'imperfect competition' wouldn't land).
3. Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
Your own comment claims that "actually competitive" markets can't have price discrimination. Sure, we can suppose the law of one price applies to perfectly competitive markets, but there's no sense in which a perfectly competitive markets "actually" exist at all! The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
My appeal to the airline industry as an example was not an accident. There's a very well-established literature on the relationship between competition and discrimination in the airline business. It's *certainly* not a settled question that discrimination decreases as competition intensifies. I included a classic from Stavins below that finds precisely the opposite of your claim.
My argument here isn't perfect. I can think of many flaws, many reasonable objections. But I don't think you're using any of them here.
---- Referenced paper from Stavins: https://www.bostonfed.org/publications/research-department-w...
Your premise is that if market power exists then market power is the problem rather than price discrimination. The issue is that price discrimination isn't possible without market power. Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier.
> That I suppose "market power" implies monopoly
This is not an argument you make explicitly, but it's something readers commonly assume and my point is to highlight that companies successfully engaged in price discrimination can and do have market power even if they don't have a full monopoly.
> Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
And I'm providing the 'there exists' claim for the alternative, to demonstrate that price discrimination can be (and often is) detrimental to customers without providing any countervailing benefit to any of them.
> The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
Profit doesn't really work that way. For example, if a company takes investment and uses it to buy a building to operate out of, the money not paid as rent to a landlord is added to the investor's profit, but if the company takes less investment and instead pays rent, the same money is counted as operating costs. Likewise, if you develop software needed before you can start operating and you take investment to pay for it, the net returns are called profit, but if you take a bank loan to pay for it then the interest on the loan is counted as operating costs again. The interest rate you'd pay the bank would even be proportional to the risk you'd fail, unless you post collateral, for which you'd need an investor.
So a company that didn't take any investment and operated entirely by renting everything, taking loans and using off-the-shelf software instead of developing anything in-house wouldn't be expected to make any profits in a perfectly competitive market -- and there would also be no investors to pay any profits to. Profit in companies that take investment would still be present and equal the cost (time value) of the assets bought with the money, but in a perfectly competitive market this would exactly equal the risk-adjusted market rate of return in the overall capital markets.
The distinction in uncompetitive markets is that profit exceeds that amount. (Or at least can; a market can be uncompetitive and then the companies become inefficient from lack of competitive pressure and waste the money they extract from customers instead of returning it to investors.)
It's true that "perfectly" competitive markets don't exist in the same sense that perfect anything doesn't exist, but this is splitting hairs. A gold coin might be .999 gold and you can say that it isn't perfect but you can still distinguish it from a wooden nickel.
"Overcharging" is a concept without a precise meaning. The SSO-capable version has a feature that cost money to build and support. That it is sold at a higher price (often alongside other enterprise features that cost money to build and support) is not proof that they are overcharging.
Any company that is tying to recoup the costs of building those features will charge the customers that use those features. The existence of a price differential between the 2 editions does not tell you whether they are overcharging.
"Price discrimination" is charging a higher price to one set of customers than another. The premise is that they're really getting the same thing but one of them has to pay more in exchange for either nothing or for something whose incremental underlying cost is far less than the incremental price increase, because the company devised a way to artificially segment the market.
If your argument is that the extra feature would actually cost that much even in a highly competitive market because it costs that much more to provide it, what you're really arguing is that they're not engaged in price discrimination.
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.
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.
I’ve been around product development for 20+ years and I have NEVER seen a feature that “no-one ever wanted” get a lot of development resources.
What I see a lot are features that a few huge customers want get those resources, and other people without that perspective write them off as useless. Meanwhile we’re closing 9 figure deals on the backs of those “useless” features.
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.
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.
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.
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
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.
SSO is a hard requirement for us.
There have been many, many times where we've considered an application where we could justify the spend at, e.g., the departmental level for the limited user base that needed it, but where SSO being bundled into higher price tiers combined with minimum user counts took a potential solution from "very easy discretionary spend" to "not happening, full stop."
I'm often the one having to make these decisions. It's absolutely exhausting having to explain to non-technical department heads that "yes, this would solve your problem at a price that fits budget, but the vendor bundles a vital security feature into a tier that inflates the price to a point that it makes this unfeasible."
Either way, it's a surefire way for a potential vendor to automatically get lower priority from me as a potential buyer. Needing to haggle over what is, for us, a baseline security feature starts things off on the wrong foot.
I think it might be worth saying “SSO is free, up to n users”.
Also this is pricing for “adequate security”, which rubs a lot of people the wrong way.
But I do agree, competent, organizational wide SSO with SCIM is definitely an enterprise feature.
That being said, obviously this situation as described sucks and we should not move towards it because really all it does is push SaaS startups towards these two vendors to punt huge licensing fees down the road until they have the revenue to support it. And by then they are significantly locked in to these specific two vendors, two vendors that already have problematic approaches to monopolizing certain things. So fixing this is important but for a different reason than one might take at face value.
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
I think what annoys people is the reason why: a way to make more money from enterprises, and that they could make that money some other way.
If the landlord had to hire a bunch of extra support people, with expertise outside their normal domain, just to support swipe cards then this would make sense, no?
I can imagine a lot of products where accompany literally could not afford to provide support for SSO issues to a basic tier customer with 100 employees
The swipe system should be a very minor or zero part of the rent, not double.
And that’s assuming you don’t include auth in any of your release testing cycles (which you should). If you do, now you’re including unit and end to end testing with Okta, MS, Google, OneLogin, Jumpcloud, Ping, and anyone else your customers choose to use.
Don’t forget to run those tests with both SAML and OIDC. And make sure the engineers who know how to co figure each of those vendors’ SSO systems are aligned with your testing schedules.
Also don’t forget that you need dev/partner accounts with all of those vendors. And they’ll need to be active when you test.
This isn't a valid analogy to SSO. SSO doesn't just cost extra to develop (which in itself is a valid reason for charging more), but it costs extra to maintain - you can find several other comments in this thread alone talking about how difficult it is to support SSO from a technical/customer service perspective. People are expensive - both when writing code, and when supporting it.
If customers need additional human support for SSO then that can be charged separately.
In my experience most customers can get it working with no hassles or have hassle but their own tech resources figure it out. Few need to get support.
As a feature it is probably less work to implement and maintain than the simplest of product features.
YMMV if you have a complicated integration but if you just want to sign people in and assign them to a group for security it isn't hard.
Maybe we are talking cross purposes? I am talking about SSO with SAML and IdP rather than OAuth.
I suspect the reason for the SSO Tax is it is an predictor of "does this customer have money". Customers with more money to spend and absolutely need SSO to meet their policies will overlap alot.
Aren't the majority of enterprise contracts negotiated with support included? I thought that that was one of the main value adds for medium-to-larged sized companies.