Vendors that treat single sign-on as a luxury feature
94 comments
·August 19, 2025tptacek
Aurornis
> 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
> 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
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
> 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.
TylerE
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
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.
vosper
> 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
> 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
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
Can you clarify, are you suggesting that the bills footed by large orgs that require SSO are paying the bills for these features?
0cf8612b2e1e
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
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
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
Yes, your 2 seat small business isn't paying the bills.
jaggederest
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
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
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
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
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
What are your normative views on this topic?
fabian2k
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
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
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
>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"] }
grinich
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 :))
grinich
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
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
No, it's far, far smaller and very specialized software.
NegativeLatency
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
God forbid the evil IT department just wants you to have the same username everywhere
SkyPuncher
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
> 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
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
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
> 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
erikerikson
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
A lot of premium or business plans don't offer SSO either. It's Enterprise or bust 9 times out 10
naniwaduni
The end of the sales funnel is Enterprise, yes.
esseph
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
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
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
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
> 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.
jjcm
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
if you need SSO you have money
if you need SSO but you don’t have money, you have issues
simplyinfinity
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.
mungoman2
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
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
I would call it obvious instead of clever, but otherwise fully agreed.
mmerickel
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
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...
null
adrr
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).
lsb
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
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
This comment clears things up. As setting up Google/Discord with Better Auth wasn't particularly hard for one of my home projects.
This pops up on HN about once a year, and it's worth calling out that the SSO tax has mostly nothing to do with technology or with support costs and mostly everything to do with market segmentation. One of the clearest segmentation signals you get is that bigger, less price-sensitive customers all require SSO (because their SOC2 attestations require it).
You can get irritated about pricing systems that soak price-insensitive customers, but remember that the big price-insensitive customers pay for the price-sensitive customers, which is why this kind of segmentation is practically universal.
Previously, on this, from me:
https://news.ycombinator.com/item?id=29892664