This pops up on HN about once a year, and it's worth calling out that the SSO tax has mostly nothing to do with technology or with support costs and mostly everything to do with market segmentation. One of the clearest segmentation signals you get is that bigger, less price-sensitive customers all require SSO (because their SOC2 attestations require it).
You can get irritated about pricing systems that soak price-insensitive customers, but remember that the big price-insensitive customers pay for the price-sensitive customers, which is why this kind of segmentation is practically universal.
> but remember that the big price-insensitive customers pay for the price-sensitive customers
The fallacy is thinking that the alternative is for everyone to pay the lower price and get the enterprise features.
In reality, without market segmentation a singular price for everyone would fall much closer to the enterprise price than the non-enterprise price.
You can call it an SSO tax, but it would be equally correct to refer to the lower price as the non-corporate discount.
mr_toad · 23m ago
> In reality, without market segmentation a singular price for everyone would fall much closer to the enterprise price than the non-enterprise price.
That totally depends on the relative elasticity of supply and demand.
It’s not very intuitive, but price discrimination (usually) results in too much demand for a good/service and a deadweight loss of consumer surplus. In the worst case scenario all consumer surplus can be arrogated to the producer, and an extreme oversupply of the product. Imagine a cheap drug that could be sold for whatever amount of money the consumer had available.
cj · 58m ago
Are you saying companies should provide a discount for not using SSO?
Or charge everyone the enterprise price to remove segmentation altogether?
Edit: I think I see what you’re saying. Although you’d likely welcome the same criticism if you refer to it as the non-corporate discount.
YetAnotherNick · 39m ago
> Although you’d likely welcome the same criticism if you refer to it as the non-corporate discount.
Why? eg no one questions students discounts.
cj · 6m ago
I’m not saying it’s a bad idea.
Only saying it won’t satisfy the people who don’t like the “SSO tax”.
There’s no difference between giving someone a discount vs. charging them less in the first place without a discount.
It’s semantics. It wouldn’t actually change what people end up paying at the end of the day. It’s just framed as a discount instead of an upsell.
Like if airline charged first class prices, but gave a “discount” for accepting an economy seat. (Same thing, just framed differently)
TylerE · 40m ago
Why not? Just like some companies offer discount plans that come with no/very limited tech support, and others charge 10 or 20x for the same product bundled with a high level of support.
mooreds · 1h ago
I like Patio11's characterization[0]:
> The right way to think of the "SSO tax" (where companies charge extra for security features) is "You are being offered a dual use product backed by a strong engineering team for far less than it would otherwise cost, with sophisticated enterprises picking up the slack."
That said, TLS/SSL used to be the preserve of the enterprise too (or at least the ecommerce site).
There are lots of free options, including 3rd party servers and libraries. I'm hoping eventually SSO will be, if not in free versions, at least not isolated to enterprise plans.
> mostly nothing to do with technology or with support costs
Support costs aren't zero though. I work for a company with a lot of corporate customers and we get loads of SSO support tickets. People are always misreading the docs, (mis)configuring things against our recommendations, migrating systems, merging systems (due to acquisition etc)...
jedberg · 45m ago
> and it's worth calling out that the SSO tax has mostly nothing to do with technology or with support costs
I'm surprised this is at the top. My experience, and the experience of nearly all the commenters below, is that SSO is by far the biggest support burden they have.
SSO costs extra because it costs extra to support them. Market segmentation is a nice side effect though.
erazor42 · 4m ago
Agree, I have implemented a few provider and every time they implemented their own interpretation of the spec. In the end you end up checking each provider to make sure everything works as expected.
ryanisnan · 1h ago
Can you clarify, are you suggesting that the bills footed by large orgs that require SSO are paying the bills for these features?
0cf8612b2e1e · 1h ago
I think the implication is that without a few whale customers, the minimum price would be significantly higher for everyone. The SSO whales subsidize everyone else.
bryanrasmussen · 1h ago
I sort of feel that the way most software pricing works is that it is the big customers who pay for features in everything and the small customers get brought along for the ride, in short I think it's the same as SSO for basically all functionality.
mikepurvis · 1h ago
I expect like any industry, most SaaS operations are floated by a smaller number of whale customers, and everyone else is running a lot closer to (or at) break even in terms of cost, but serve as advertising, testing, and vendor-validation that allows that next whale to pull the trigger.
trollied · 1h ago
Yes, your 2 seat small business isn't paying the bills.
jaggederest · 1h ago
It's true both in the micro sense ("We wouldn't have developed the headache that is SSO without a cornerstone customer demanding it and paying $XXXk"), and in the macro sense ("Our business would not be a going concern without the significant revenue provided by enterprise customers")
ryanisnan · 7m ago
Interesting. I wouldn't have thought that running an SSO integration is that painful. I've done it before, albeit for a single enterprise client, and while annoying at first, after delivery was just like another feature.
hackitup7 · 1h ago
Thank you for adding some sanity to this discussion – this is ultimately a matter of economics, and the R&D effort to add and maintain these features is not trivial.
sparrish · 1h ago
I think you missed the point. The costs isn't insomuch R&D, it's in support. Users struggle with SSO and so we get tickets; techs answering tickets costs money.
ghostpepper · 11m ago
shouldn't every new company be using SSO for everything in 2025 and beyond? how long before this no longer becomes a good signal?
sunshowers · 10m ago
What are your normative views on this topic?
cubefox · 1h ago
Similar reason why there is a big price difference between DVDs and Blu-rays, and why DVDs still exist in the first place.
RedShift1 · 47m ago
They still make new DVD's?
TylerE · 35m ago
And they still outsell Blu-ray.
It’s mostly lots and lots of kids tv. Kids don’t know what 480p means and parents just want discs that are cheaper and more resistant to damage.
bombcar · 14m ago
Exactly this - and sometimes they don't even bother with two SKUs and give you both in the same container for the DVD price.
A surprising percentage of the population cannot tell a DVD from a Blu-ray in motion at home, especially if their TV does upscaling.
zoeysmithe · 1h ago
I think this is overly complimentary to big business and what's essentially predatory pricing.
The reality is you can't just carve out on feature and say "we pay for this." I mean that's true of a lot of things. The big revenue generators pay for a lot of things, but how things are billed is important. Remember, not to long ago people paid for Netscape, but now its laughable to pay for a browser. Its arbitrary to have this 'buffet' mentality and seems purposely shaming towards people who rightfully complain about ridiculous pricing structures like this.
I'm also skeptical that SSO costs vendors money. Maintaining and supporting an authentication database is a huge expense. For every SSO client, its one less Adobe or whatever account that needs to be hosted. Less helpdesk tickets about password resets, etc. SSO tends to be once and done. Hosting millions of accounts and being the sign-on provider for them is not 'once and done.'
Lastly, a lot of orgs don't do this. A lot arent SOC2. That means they'll just use whatever account the vendor supplies, and most likely without MFA, but their SSO would have provided that, thus making everyone more vulnerable. This is a great example of how exec salaries and stock buybacks and other things have priority over security because security is seen as a cost-center and without litigation or law, stuff like this becomes the norm. Oh and now there's one more source of passwords out there and another potential hack.
This is just greed and predatory. Its not the wonderful largess of big companies. It fact, its quite the opposite.
viraptor · 58m ago
> Less helpdesk tickets about password resets, etc.
Pretty much everyone knows the password reset flow these days. Even if they do manage to lose access to everything somehow, the process to restore is mostly standard. On the other hand, SSO issues are long, annoying, and involve engineers rather than first level support. Source: my weeks long support tickets with Okta.
Analemma_ · 35m ago
> I'm also skeptical that SSO costs vendors money
Sane SSO from clients with clean setups doesn’t cost vendors much money. But take it from someone who has done this work: that’s rarely the case for the megacorps who want SSO integration. They tend to have horrifying AD/Oauth monstrosities, with back-compat requirements that will break your mind and sysadmins of questionable competence. These require lots of bespoke code and lots of meetings— meaning, lots of man-hours that senior ICs are not spending on product— to get right.
That’s where a lot of the money for SSO is going, and you can’t exactly say “the price depends on how shit your backend is”, so it has to be enough to prepare for the worst.
medlazik · 1h ago
Small orgs don't need to be SOC2 to have client contracts that require SSO. This is absolute fucking evil behavior and this page shouldn't exist anymore in 2025.
akavi · 45m ago
It's evil to sell a product for a price higher than you, personally, want to pay?
maxrmk · 51m ago
Evil feels strong? Small companies benefit from having the basic feature set subsidized by big cos. It's kind of hard for me to imagine a scenario where pricing of a saas product could be _evil_. you can just choose not to do business with them!
fabian2k · 1h ago
Not to defend this practice, but SSO does tend to produce an additional support burden. It's complex, there are many knobs to fiddle with and it can be tedious to figure out if the customer (via configuration, or their identity provider itself) or the vendor are at fault for an issue.
Just had an issue today, I'm reasonably sure it's the customer's fault. But I also misread the spec earlier and was wrong about some parts that worked out of the box with one identity provider, but not another one. So who knows. Okay, I assume this parts gets better once your SSO implementation gets older, but it's a pain when you're starting out with it.
stackskipton · 1h ago
Yep, I used to deal with this at $LastJob and amount of support burden was terrible.
Azure AD/Entra ID (Microsoft IDP) was most common and amount of IT folks who don't have a clue about it is staggering.
Companies kicking over issues to us when it's their problem. "Hey, we have a ticket saying MFA Required but account shows as Entra ID." "Send it back with contact their IT team." "Their IT team opened the ticket" rage screaming
Companies not following setup instructions. I used to provide Terraform, Powershell and Graphical setup. I can count on one hand how many people used Terraform/Powershell. This was always dicey because I got familiar with the error messages and would be "Yep, this was not setup right on their end." I had 4 phone calls with $CustomerIT swearing it was setup properly and stopped attending after that. Finally they got someone with a brain to review and finished setup.
Documentation would fall out of date because of some UI change and I'd spend a day reviewing it and updating it.
mikestorrent · 1h ago
To be fair, Entra is an abysmally bad user experience; their support barely knows anything about it. Provisioning is clunky and slow. Applications are split into two halves. Self-service password reset is a half-finished joke.
Tip of the iceberg: adding a custom field to a user record is possible, but you need to use the Graph API to do it; once you've added it, it is never visible on any UI, you can only get the data back out via API. So good luck making a custom field that your clerical staff can actually work with.
There's Terraform support to add applications to it, but you end up having to go in and click "grant admin consent"... no way to do the whole thing IaC without a bit of manual interaction. Maybe that's a good thing? Annoying anyway.
stackskipton · 1h ago
>There's Terraform support to add applications to it, but you end up having to go in and click "grant admin consent"... no way to do the whole thing IaC without a bit of manual interaction. Maybe that's a good thing? Annoying anyway.
Previous customer IT support staff, is that you? I kid.
I started a startup to fix this exact problem integrating and configuring SSO/SAML.[0]
We launched here on HN 5 years ago[1] and today power SSO for OpenAI, Cursor, Vercel, and a thousand other apps. We also found the initial configuration step to be painful for users, so we built a self-serve wizard that enables enterprise admins to fix issues.[2]
It's still crazy how much complexity there is with enterprise identity systems and managing the user lifecycle for big orgs. It's like the whole thing is made of weird edge cases and even moreso when you add SCIM, RBAC, MFA, etc etc.
(If anyone reading this also loves suffering at the intersection of IAM and developer tools, we are hiring! Email in my profile :))
also if anyone wants to go down the rabbit hole about why SAML is hard to implement, this is a pretty interesting writeup of a major 0-day vuln we discovered earlier this year: https://workos.com/blog/samlstorm
9dev · 1h ago
Are you working for Stripe and the issue is names not syncing via SCIM perchance? In that case I’m the customer and reasonably sure it’s your fault ;)
fabian2k · 1h ago
No, it's far, far smaller and very specialized software.
NegativeLatency · 1h ago
Especially so if the customer is not a tech company or otherwise has IT staff that aren't uh motivated.
Add in SCIM and IT people "changing stuff to better align with our other stuff" and you just get a whole steamy barrel of fun.
mikestorrent · 1h ago
God forbid the evil IT department just wants you to have the same username everywhere
SkyPuncher · 1h ago
At a past company, we had discussion about this exact topic. Despite wanting to offer SSO on a free/low-tier, we simply could not justify it.
SSO was by far our most expensive feature to support. It was the single largest bucket of support requests and a significant percentage of those requests required an engineer to get on a call with a customer (and their IT team).
We evaluated building better product/tooling to self-serve, but we realized that it likely wouldn’t solve the issue. SSO is security critical, so anytime things go wrong people throw their hands up and say “nope, I’m not the one that’s going to hurt my company”. They really just needed someone on our end to give them confidence.
Don’t get me wrong, we fixed many of the biggest issues - but there’s an endless supply of crap that can go wrong.
Aurornis · 1h ago
> SSO was by far our most expensive feature to support. It was the single largest bucket of support requests and a significant percentage of those requests required an engineer to get on a call with a customer (and their IT team).
I can confirm this is how it goes.
You can theorize about how SSO should be straightforward or self-serve, but in practice the SSO feature creates a disproportionately large support and engineering burden.
When you’re dealing with SSO support for a customer buying 100 expensive seats it can be easy to justify.
When you’re debugging the SSO for some small shop with 3 licenses who will churn suddenly the moment their lead noticed a shiny new competitor, it’s not worth it.
lousken · 1h ago
Sorry but that just means the feature is difficult to use on either side, so that would be at least 50% of your problem anyway. Provide good docs? How about that?
Every time someone has a problem create docs for it and after some time those questions will reduce significantly.
edit: also, for people implementing this the first time it should be obvious what happens when
1) they create a new account in your app (local)
2) if they create a new account within SSO provider
3) what happens with existing accounts during setup and if current users will be migrated over or not (or if they can use both singins)
fabian2k · 1h ago
Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities.
And customers don't necessarily read the docs, or even if they do they don't configure everything correctly.
And we're not even at customization that is particular to the customer. How to represent that in their identity provider and how to get your application to follow that in the way the customer expects.
lousken · 1h ago
> Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities.
no, you just provide the most used ones, once you have like top 5, that helps a lot
> And customers don't necessarily read the docs, or even if they do they don't configure everything correctly.
so just like with any other feature, really
also you should be improving docs, if they are not clear, make them clearer
it's basic sysadmin stuff, eventually 90% will understand and 10% will ask regardless of what you do, so just embrace yourself for those occasions
stackskipton · 55m ago
>also you should be improving docs, if they are not clear, make them clearer
I've written the docs with a tons review and feedback, this saying comes to mind: "Nothing is foolproof to a sufficiently talented fool"
There are no more sysadmins at most companies, it's just desktop support and maybe Office365 admin who was desktop support but got promoted because they were elite ClickOps. Powershell/Terraform, that's for those DevOps people over there and they want nothing to do with us.
lousken · 30m ago
mentioned those 10% sufficiently talented ;)
not sure about US, but here in center of europe we still have sysadmins and not many devoops people
erikerikson · 1h ago
Whoever wrote this erroneously sees the entry level pricing as a viable product rather than just a part of the sales funnel for the customers that bring the bulk of buying power and revenue.
derektank · 57m ago
A lot of premium or business plans don't offer SSO either. It's Enterprise or bust 9 times out 10
naniwaduni · 38m ago
The end of the sales funnel is Enterprise, yes.
esseph · 1h ago
Every shop should have SSO, period, as a security requirement.
Not offering SSO outside of extremely expensive "Enterprise Plans" is actually hurting national security by segmenting access / control / auditing.
It sucks. Either vendors need to offer SSO across the board on much lower plans, or the Fed Gov needs to step up and help subsidize costs for the CISA 16 identified critical infrastructure sectors.
throwup238 · 1h ago
Some of these numbers don’t quite make sense. AppSmith has the highest percentage increase (16567%) but that’s because the minimum is 100 seats, so the actual number is $25/mo or 66% increase. How often do vendors enforce these minimums? I’ve never had a problem getting past them (at least with small to medium sized SaaS companies) when contacting sales as long as I had a few tens of users.
I really appreciate Cloudflare not putting SSO behind a paid subscription because using their Cloudflare Access product with Github SSO has been the easiest way to secure my personal services running on a VM.
arjvik · 1h ago
Out of curiosity, why GitHub as the SSO provider? Am thinking about local SSO for my homelab and was debating passkeys vs tying to Google accounts.
throwup238 · 54m ago
I don't use Google or any other SSO account except for work so my personal Github just made the most sense. It was also trivial to set up without digging through layers of UI.
neilv · 1h ago
> Single sign-on (SSO) is a mechanism for outsourcing the authentication for your website (or other product) to a third party identity provider, such as Google, Okta, Entra ID (Azure AD), PingFederate, etc.
Or the IdP is administered by the enterprise's own IT operation.
The outsourcing of your security to (and also consequently leaking information to) a third party IdP is a fairly new phenomenon in 'security'.
Someone must have paid a lot of money to promote that idea.
axus · 1h ago
But I really like checking my email without signing in to a VPN.
neilv · 10m ago
An IdP doesn't have to be on a VPN, no matter who operates it.
jjcm · 1h ago
I agree with the sentiment in theory but disagree in practice.
The way I typically look to segment and price things is by billing based on organizational complexity rather than gating end-user features whenever possible. If something is a specific need for a large org, it should be a higher tier, since those organizations typically have a larger ability to pay. If it's something that a single seat user would want if they were an expert, I'd rather not tier on that - it basically would be shitting on your largest segment of superusers / fans / influencers for most B2C apps.
Put a different way, if I were subscribing to MS Paint, I'd rather have to pay more for SAML/SCIM provisioning than to pay for the number of particles the spray paint tool can output at once. One limits orgs, the other limits users. You should never limit users without reason.
baq · 1h ago
if you need SSO you have money
if you need SSO but you don’t have money, you have issues
simplyinfinity · 1h ago
I self host a bunch of apps that have SSO as enterprise feature. i want to invite my family/friends into these apps, i don't wanna spend additional 20 000$ for the SSO part, but it be real sweet if i could use it.
It would eliminate so much questions like "hey.. what was my login to X?" or "can you reset my password to Y" if i could just use SSO.
rawfan · 1h ago
Just use oauth2-proxy with keycloak to put SSO in front of any self-hosted app.
NewJazz · 1h ago
Works if everyone has the same permissions in the app but you might still need a shared login as well. I've done this for e.g. metabase before but it is not the same as a native oidc integration.
mungoman2 · 1h ago
Yes, agreed. What we see is simply a clever way to differentiate the customers that can pay a premium from those that can't. The end goal is to extract the maximum amount of money.
tptacek · 1h ago
Or, equivalently, to enable the largest number of customers to use the product, by decreasing prices for smaller customers and increasing them for large ones.
baq · 1h ago
I would call it obvious instead of clever, but otherwise fully agreed.
mmerickel · 1h ago
This is just flat-out untrue, OIDC or SAML plus SCIM should be the default for any enterprise-focused service provider or "you're doing it wrong". You can offer your own IDP as the default, but all of the problems that need to be solved to allow your customers to configure their own IDP are important to the design/architecture of your service and the only reason these providers are treating it as special is because they didn't build the integration between their service and their IDP correctly the first time. Provisioning and authentication are critical to security and you're actively harming your customers if you require them to use your own IDP solution in order to use your service.
datadrivenangel · 1h ago
As a volunteer at a volunteer run non-profit, I agree! Nobody makes any more at the org, and it would be great to have SSO for things without having to pay more 150% of our total annual budget to get it...
adrr · 1h ago
If I ran a saas company, i would charge more for users not use to SSO. Bigger risk storing passwords and managing login process(2FA, password reset etc).
sparrish · 58m ago
If you ran a saas, you'd know how much more supporting SSO costs and sing a different tune.
beacon473 · 33m ago
Why do some sites require SSO, without an option for a local (better term?) account?
I prefer to have a unique username and password for each service. KeepassXC is my SSO provider.
lsb · 25m ago
Also: this SSO tax is deceptively framed. Many of these services allow one to sign in through, for example, Google, which can count as a single sign on, and many organizations have a mail account, but that isn’t taken into account.
legitster · 58m ago
Maybe I'm missing something. Nearly every one of these companies offers SSO on their basic plans through the big public IdPs (Google, GitHub, Microsoft, etc).
What's being advertised as a feature is not SSO, but SSO through a private IdP. So this could just be a case of confusion created through marketing simplification.
Which, fair game! If you are big or technical enough to need a private IdP, you should probably be paying for an Enterprise plan. And from the perspective of these software companies, supporting your third-party IdP is kinda a luxury feature. Moreover, I can understand why Adobe wouldn't want to include these advanced features in their plans for college students.
holbrad · 32m ago
This comment clears things up. As setting up Google/Discord with Better Auth wasn't particularly hard for one of my home projects.
sirjaz · 1h ago
This is just more justification to bring software back onprem and kill SaaS.
ian-g · 1h ago
I don't think it's necessarily _wrong_ to say that SSO shouldn't just be an enterprise feature, but if you need to hire an additional person or two just for SSO, you should feel free to pass that cost (plus a cushion) on.
robertkoss · 1h ago
Its the same if you sell B2B software and have to offer SSO to your customers. Every auth provider like Auth0, Clerk, WorkOS etc. increases their prices tremendously if you require SSO...
mamcx · 1m ago
And then if you need multi-tenant...
mooreds · 1h ago
Disclosure, I work for FusionAuth.
heya robertkoss, FusionAuth is software you can run yourself for free which is comparable to Auth0, Clerk, WorkOS. We have a community plan with unlimited SSO providers (SAML and OIDC; sorry, we don't support WS-Fed).
That's why single sign on is so great, every single vendor has their own way of implementing it.
time4tea · 23m ago
Any company that does this, but yaks on about 2fa/security is just gaslighting you.
Sane for those that only offer 2fa as part of cost plus deal.
SSO or 2fa are table stakes for companies that care about you - even at a free tier.
Both are effectively zero cost to deploy (once you create the login capability for one) ...
coldcode · 1h ago
I once worked a contract at a public University, and the first thing I noticed was their SSO implementation. You logged into a single page, and then it called the other applications with a GET putting the username and password in the clear in the URL. Facepalm.
supportengineer · 1h ago
I once worked at a company in the Healthcare space that acquired a small company for $10 million. When the deal closed and they showed us the Patient Portal, the first thing I noticed was no HTTPS. At all. Just plain HTTP everywhere.
karel-3d · 1h ago
SSO is actually really annoying to implement well.
Better cash up
worik · 1h ago
That list of firms is a wall of shame, period
z3ratul163071 · 1h ago
thank you for this. i also found this few years back, incredibly annoying.
phito · 1h ago
I wanted to try using n8n in my homelab, but was very disappointed to see the SSO behind a paywall even in the community edition. Bit of a deal breaker for me unfortunately.
Our_Benefactors · 1h ago
This page is unfortunately pure delusion.
I recall early in my career, I was building out a pilot version of a service. Early feedback was that users loved it, and it looked like the tool would be a good way to build our brand, but not a huge money maker. Cost per seat would be about $15/mo and we expected to sell less than 10 seats per customer. SSO integration would be a flat one-time fee in the mid four figures, and my boss laughed when he explained there was more money to be made integrating a mediocre service than selling a perfect solution behind a traditional username and password login.
dvrp · 1h ago
in the real world you pay for extra security; yet developers think that this should be free just cuz…?
bee_rider · 1h ago
I don’t think you should have to pay extra for extra security in general. Making a product or service free of security defects ought to be considered a basic requirement of merchantability.
But we should also draw a distinction between, like, real security defects (RCEs, that sort of thing) and features that might make it easier to deploy a system securely (SSO).
zdragnar · 1h ago
... Because the specifications are open. Practically the whole Internet is built on open specifications. The security and operations benefits are obvious for enterprise customers. Startups could also benefit greatly from it, but the cost ramping of the large providers is onerous.
You can get irritated about pricing systems that soak price-insensitive customers, but remember that the big price-insensitive customers pay for the price-sensitive customers, which is why this kind of segmentation is practically universal.
Previously, on this, from me:
https://news.ycombinator.com/item?id=29892664
The fallacy is thinking that the alternative is for everyone to pay the lower price and get the enterprise features.
In reality, without market segmentation a singular price for everyone would fall much closer to the enterprise price than the non-enterprise price.
You can call it an SSO tax, but it would be equally correct to refer to the lower price as the non-corporate discount.
That totally depends on the relative elasticity of supply and demand.
It’s not very intuitive, but price discrimination (usually) results in too much demand for a good/service and a deadweight loss of consumer surplus. In the worst case scenario all consumer surplus can be arrogated to the producer, and an extreme oversupply of the product. Imagine a cheap drug that could be sold for whatever amount of money the consumer had available.
Or charge everyone the enterprise price to remove segmentation altogether?
Edit: I think I see what you’re saying. Although you’d likely welcome the same criticism if you refer to it as the non-corporate discount.
Why? eg no one questions students discounts.
Only saying it won’t satisfy the people who don’t like the “SSO tax”.
There’s no difference between giving someone a discount vs. charging them less in the first place without a discount.
It’s semantics. It wouldn’t actually change what people end up paying at the end of the day. It’s just framed as a discount instead of an upsell.
Like if airline charged first class prices, but gave a “discount” for accepting an economy seat. (Same thing, just framed differently)
> The right way to think of the "SSO tax" (where companies charge extra for security features) is "You are being offered a dual use product backed by a strong engineering team for far less than it would otherwise cost, with sophisticated enterprises picking up the slack."
That said, TLS/SSL used to be the preserve of the enterprise too (or at least the ecommerce site).
There are lots of free options, including 3rd party servers and libraries. I'm hoping eventually SSO will be, if not in free versions, at least not isolated to enterprise plans.
0: https://x.com/patio11/status/1481293027331440640
Support costs aren't zero though. I work for a company with a lot of corporate customers and we get loads of SSO support tickets. People are always misreading the docs, (mis)configuring things against our recommendations, migrating systems, merging systems (due to acquisition etc)...
I'm surprised this is at the top. My experience, and the experience of nearly all the commenters below, is that SSO is by far the biggest support burden they have.
SSO costs extra because it costs extra to support them. Market segmentation is a nice side effect though.
It’s mostly lots and lots of kids tv. Kids don’t know what 480p means and parents just want discs that are cheaper and more resistant to damage.
A surprising percentage of the population cannot tell a DVD from a Blu-ray in motion at home, especially if their TV does upscaling.
The reality is you can't just carve out on feature and say "we pay for this." I mean that's true of a lot of things. The big revenue generators pay for a lot of things, but how things are billed is important. Remember, not to long ago people paid for Netscape, but now its laughable to pay for a browser. Its arbitrary to have this 'buffet' mentality and seems purposely shaming towards people who rightfully complain about ridiculous pricing structures like this.
I'm also skeptical that SSO costs vendors money. Maintaining and supporting an authentication database is a huge expense. For every SSO client, its one less Adobe or whatever account that needs to be hosted. Less helpdesk tickets about password resets, etc. SSO tends to be once and done. Hosting millions of accounts and being the sign-on provider for them is not 'once and done.'
Lastly, a lot of orgs don't do this. A lot arent SOC2. That means they'll just use whatever account the vendor supplies, and most likely without MFA, but their SSO would have provided that, thus making everyone more vulnerable. This is a great example of how exec salaries and stock buybacks and other things have priority over security because security is seen as a cost-center and without litigation or law, stuff like this becomes the norm. Oh and now there's one more source of passwords out there and another potential hack.
This is just greed and predatory. Its not the wonderful largess of big companies. It fact, its quite the opposite.
Pretty much everyone knows the password reset flow these days. Even if they do manage to lose access to everything somehow, the process to restore is mostly standard. On the other hand, SSO issues are long, annoying, and involve engineers rather than first level support. Source: my weeks long support tickets with Okta.
Sane SSO from clients with clean setups doesn’t cost vendors much money. But take it from someone who has done this work: that’s rarely the case for the megacorps who want SSO integration. They tend to have horrifying AD/Oauth monstrosities, with back-compat requirements that will break your mind and sysadmins of questionable competence. These require lots of bespoke code and lots of meetings— meaning, lots of man-hours that senior ICs are not spending on product— to get right.
That’s where a lot of the money for SSO is going, and you can’t exactly say “the price depends on how shit your backend is”, so it has to be enough to prepare for the worst.
Just had an issue today, I'm reasonably sure it's the customer's fault. But I also misread the spec earlier and was wrong about some parts that worked out of the box with one identity provider, but not another one. So who knows. Okay, I assume this parts gets better once your SSO implementation gets older, but it's a pain when you're starting out with it.
Azure AD/Entra ID (Microsoft IDP) was most common and amount of IT folks who don't have a clue about it is staggering.
Companies kicking over issues to us when it's their problem. "Hey, we have a ticket saying MFA Required but account shows as Entra ID." "Send it back with contact their IT team." "Their IT team opened the ticket" rage screaming
Companies not following setup instructions. I used to provide Terraform, Powershell and Graphical setup. I can count on one hand how many people used Terraform/Powershell. This was always dicey because I got familiar with the error messages and would be "Yep, this was not setup right on their end." I had 4 phone calls with $CustomerIT swearing it was setup properly and stopped attending after that. Finally they got someone with a brain to review and finished setup.
Documentation would fall out of date because of some UI change and I'd spend a day reviewing it and updating it.
Tip of the iceberg: adding a custom field to a user record is possible, but you need to use the Graph API to do it; once you've added it, it is never visible on any UI, you can only get the data back out via API. So good luck making a custom field that your clerical staff can actually work with.
There's Terraform support to add applications to it, but you end up having to go in and click "grant admin consent"... no way to do the whole thing IaC without a bit of manual interaction. Maybe that's a good thing? Annoying anyway.
Previous customer IT support staff, is that you? I kid.
resource "azuread_service_principal_delegated_permission_grant" "grant" { service_principal_object_id = blah resource_service_principal_object_id = blah claim_values = ["openid"] }
No comments yet
We launched here on HN 5 years ago[1] and today power SSO for OpenAI, Cursor, Vercel, and a thousand other apps. We also found the initial configuration step to be painful for users, so we built a self-serve wizard that enables enterprise admins to fix issues.[2]
It's still crazy how much complexity there is with enterprise identity systems and managing the user lifecycle for big orgs. It's like the whole thing is made of weird edge cases and even moreso when you add SCIM, RBAC, MFA, etc etc.
(If anyone reading this also loves suffering at the intersection of IAM and developer tools, we are hiring! Email in my profile :))
[0] https://workos.com
[1] https://news.ycombinator.com/item?id=22607402
[2] https://workos.com/admin-portal
Add in SCIM and IT people "changing stuff to better align with our other stuff" and you just get a whole steamy barrel of fun.
SSO was by far our most expensive feature to support. It was the single largest bucket of support requests and a significant percentage of those requests required an engineer to get on a call with a customer (and their IT team).
We evaluated building better product/tooling to self-serve, but we realized that it likely wouldn’t solve the issue. SSO is security critical, so anytime things go wrong people throw their hands up and say “nope, I’m not the one that’s going to hurt my company”. They really just needed someone on our end to give them confidence.
Don’t get me wrong, we fixed many of the biggest issues - but there’s an endless supply of crap that can go wrong.
I can confirm this is how it goes.
You can theorize about how SSO should be straightforward or self-serve, but in practice the SSO feature creates a disproportionately large support and engineering burden.
When you’re dealing with SSO support for a customer buying 100 expensive seats it can be easy to justify.
When you’re debugging the SSO for some small shop with 3 licenses who will churn suddenly the moment their lead noticed a shiny new competitor, it’s not worth it.
Every time someone has a problem create docs for it and after some time those questions will reduce significantly.
edit: also, for people implementing this the first time it should be obvious what happens when
1) they create a new account in your app (local)
2) if they create a new account within SSO provider
3) what happens with existing accounts during setup and if current users will be migrated over or not (or if they can use both singins)
And customers don't necessarily read the docs, or even if they do they don't configure everything correctly.
And we're not even at customization that is particular to the customer. How to represent that in their identity provider and how to get your application to follow that in the way the customer expects.
no, you just provide the most used ones, once you have like top 5, that helps a lot
> And customers don't necessarily read the docs, or even if they do they don't configure everything correctly.
so just like with any other feature, really
also you should be improving docs, if they are not clear, make them clearer
it's basic sysadmin stuff, eventually 90% will understand and 10% will ask regardless of what you do, so just embrace yourself for those occasions
I've written the docs with a tons review and feedback, this saying comes to mind: "Nothing is foolproof to a sufficiently talented fool"
There are no more sysadmins at most companies, it's just desktop support and maybe Office365 admin who was desktop support but got promoted because they were elite ClickOps. Powershell/Terraform, that's for those DevOps people over there and they want nothing to do with us.
not sure about US, but here in center of europe we still have sysadmins and not many devoops people
Not offering SSO outside of extremely expensive "Enterprise Plans" is actually hurting national security by segmenting access / control / auditing.
It sucks. Either vendors need to offer SSO across the board on much lower plans, or the Fed Gov needs to step up and help subsidize costs for the CISA 16 identified critical infrastructure sectors.
I really appreciate Cloudflare not putting SSO behind a paid subscription because using their Cloudflare Access product with Github SSO has been the easiest way to secure my personal services running on a VM.
Or the IdP is administered by the enterprise's own IT operation.
The outsourcing of your security to (and also consequently leaking information to) a third party IdP is a fairly new phenomenon in 'security'.
Someone must have paid a lot of money to promote that idea.
The way I typically look to segment and price things is by billing based on organizational complexity rather than gating end-user features whenever possible. If something is a specific need for a large org, it should be a higher tier, since those organizations typically have a larger ability to pay. If it's something that a single seat user would want if they were an expert, I'd rather not tier on that - it basically would be shitting on your largest segment of superusers / fans / influencers for most B2C apps.
Put a different way, if I were subscribing to MS Paint, I'd rather have to pay more for SAML/SCIM provisioning than to pay for the number of particles the spray paint tool can output at once. One limits orgs, the other limits users. You should never limit users without reason.
if you need SSO but you don’t have money, you have issues
I prefer to have a unique username and password for each service. KeepassXC is my SSO provider.
What's being advertised as a feature is not SSO, but SSO through a private IdP. So this could just be a case of confusion created through marketing simplification.
Which, fair game! If you are big or technical enough to need a private IdP, you should probably be paying for an Enterprise plan. And from the perspective of these software companies, supporting your third-party IdP is kinda a luxury feature. Moreover, I can understand why Adobe wouldn't want to include these advanced features in their plans for college students.
heya robertkoss, FusionAuth is software you can run yourself for free which is comparable to Auth0, Clerk, WorkOS. We have a community plan with unlimited SSO providers (SAML and OIDC; sorry, we don't support WS-Fed).
Here's the doc to set up an OIDC provider to Entra ID: https://fusionauth.io/docs/lifecycle/authenticate-users/iden...
We have other things we charge for (pricing here: https://fusionauth.io/pricing?step=plan ) but we don't charge per SSO connection.
Sane for those that only offer 2fa as part of cost plus deal.
SSO or 2fa are table stakes for companies that care about you - even at a free tier.
Both are effectively zero cost to deploy (once you create the login capability for one) ...
Better cash up
I recall early in my career, I was building out a pilot version of a service. Early feedback was that users loved it, and it looked like the tool would be a good way to build our brand, but not a huge money maker. Cost per seat would be about $15/mo and we expected to sell less than 10 seats per customer. SSO integration would be a flat one-time fee in the mid four figures, and my boss laughed when he explained there was more money to be made integrating a mediocre service than selling a perfect solution behind a traditional username and password login.
But we should also draw a distinction between, like, real security defects (RCEs, that sort of thing) and features that might make it easier to deploy a system securely (SSO).