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:
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.
In a monopoly, this means that the quantity supplied may be greater, but it would still be no greater than under perfect competition (necessarily so since the monopolist would never offer the product at a lower price than their MC, which is where price would be under PC). You can see this because there is no consumer that would buy under price discrimination that wouldn't buy under PC, and everyone with a WTP greater than MC buys either way.
Anyway, I agree that price discrimination results in the producer capturing more consumer surplus, but it can potentially be beneficial for those with a lower WTP in return for hurting those with a higher WTP.
To say nothing of the implicit argument that software service providers have undeserved pricing power; I think that's begging the question, but it's not really relevant to my quibble here.
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)
In most of these cases we either give up because the support is so useless, or someone high up calls Microsoft and gets the case escalated away from Accenture to someone in Microsoft who actually knows something.
Personally if I were a CIO I would really be pissed at having to pay for this kind of "support". But yeah these guys rub shoulders with Microsoft all the time who tell them it's all amazing.
> 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.
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.
One way you can see this is the case is that there are stiff SSO taxes from some vendors who don't even do custom SSO, just OIDC.
The major identity support cost is 2FA, because people constantly lose it, and you need to design and manage an account recovery process.
SSO was one of the greatest support burdens due to the numerous protocols we supported and the vast array of sometimes bizarre, often complex auth environments across the customer base.
The biggest hidden cost came from the complete lack of consistency in auth implementations from 3rd party vendors, i.e. it wasn’t enough to implement the SAML/OIDC/etc specs, because many of the systems our customers wanted to connect with had not implemented to spec.
This is all prior to dealing with 2FA which was definitely another major factor.
The company didn’t charge extra for SSO despite the support cost, also for ideological reasons. But they were also singularly focused on large enterprise customers so it was table stakes. Plenty of other platform modules to upsell.
My point was mostly to highlight that it can be costly for a bunch of reasons.
There were also privilege elevation scenarios to consider, e.g. to access highly sensitive data, the current authenticated user must enter a 2nd factor to continue.
Some of this is self-inflicted, e.g. a few of my banks only support 2FA via their own apps, so while I'd never lose my TOTP code, it's a hassle every time I lose my phone. (Or it breaks, is stolen, etc.)
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)...
Similar with other services.
Just because of SSO, as we don't have the manpower to handle the compliance stuff our customers demands otherwise.
But otherwise I believe you are very on point. Although from a developer perspective perhaps it should be segmented the other way around. If I can outsource to identity providers, I have delegated a lot of risk and work. And while the initial implementation might be a bit more cumbersome, in the long run it certainly is less development intensive than providing a complete user management interface. And maintenance for a few keys is easier than user management, even if you still have to do some of that.
Perhaps not using SSO should be marketed as some privacy focused benefit, which is more expensive.
Sure, other software needs that too. Some enterprises use their own identity provider and I would prefer that as well. Usually that is probably some windows ldap database that can easily be integrated, but there are a lot of other solutions as well.
That’s the same logic some use to explain why university fees have to exist opposed to being tax funded, because otherwise the poorer would finance the education of the wealthy totally ignoring that higher costs are the barrier that makes less likely that the poorer can study in the first place.
So the overall revenue and profit could be higher if they offer the SSO at the same price as without
You mean they more than make up for the loss of those customers? What is the underlying cost on the service? Isn't the profit margin here absolutely absurd since the underlying cost to the vendor is basically zero once their implementation is written?
SSO should be a feature for the family as well. A parent should be able to pull up a dashboard and see where all their family gmail accounts are authorized to use as a login from one screen without scrolling.
The overall sentiment that SSO creates a support burden is true, but a separate problem that should also be fixed. it _shouldnt_ be complicated for a small team with ten accounts to control group login information, revoke access, lock accounts.
Stuff costs money! That's really all there is to the analysis. You can demand that companies not price-segregate customers, but then all you're really saying is that there's no account that the local PTA can afford, because you're demanding that vendors raise prices on the low end and and drop them for customers like Apple and Ford.
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.
At work, I can’t afford free.
And honestly when I really really want SSO anyways, I can bolt on vouch proxy for free
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
"That there should be nothing magic about security to exempt it from economics."
I disagree quite strongly with this! I think a reasonable premium for SSO support costs is fine but severe price discrimination/bundling based on security features is unethical. That is because security issues have large externalities on uninvolved parties.
No, not valid. It's Atlassian's customer that's on the hook for securing their offerings to their customers. Atlassian is holding up its end of the bargain. If you don't like it, don't take them up on it! I don't!
This is all normative.
Just my opinion.
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.
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.
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.
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"] }
_allowing_ a user to configure SSO for free doesn’t require a company to offer onboarding / education help to that user. That can be offered exclusively to paying customers.
Of course we’re happy to charge them to deal with that shit.
If we don’t then they go to twitter and the trade press to shit on our product.
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 :))
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.
WorkOS does exactly this. It's "Stripe for enterprise features."
Our customers include OpenAI, Anthropic, xAI, Cursor, Perplexity, Vercel, Replit, Webflow, Clay, Hex, Carta, Plaid, Drata, Vanta, and many others. If you've used these products, you've used WorkOS!
WorkOS makes it easy to "cross the enterprise chasm." Here's a bit more of the backstory: https://x.com/grinich/status/1841569664465568248
We also launched on HN 5 years ago :) https://news.ycombinator.com/item?id=22607402
Most companies can get equivalent security and a better overall experience just using Google OAuth. The argument that you're having to pay for security features that should be available to everyone just doesn't compute for me if you offer Google/Microsoft OAuth, which most smaller companies are going to be using instead of Okta/etc to begin with.
If you really need SSO, it's probably because you're trying to manage massive amounts of user and do SCIM provisioning, etc. In which case, there probably will be some burden on the vendor to make sure that this all works smoothly or they'll pay a vendor (like us, I am biased as one of the Stytch founders).
We built an open source library, SAML Shield [1], to help companies secure their SAML implementations. And while hopefully this helps reduce the burden for teams maintaining in house SAML, the reality is that it definitely is a burden.
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.
- Providers that actually implemented SAML correctly and that we can support without being buried in tickets
- Shitty Enterprise Grade™ systems you wouldn't dare to use voluntarily
- Oh god you actually wrote your own IDP what is this cursed mess
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
On the level of “I pressed the button and nothing happened.”
Fraught with bottomless wells of silent failure.
There’s inevitably a section of dumping payloads and sometimes that’s one sided.
if you want to be competitive, get your sh*t together - this is the reason why nobody wants to bother with alternatives
Ultimately, the IT person setting up SSO is not the user of the product. "Setup SSO for X" is just another ticket in their queue. When things go wrong, not only do they want to avoid hurting their company, they don't have a strong incentive to solve that ticket right away. They just toss the ticket back to the requester and say "it doesn't work".
This is _why_ so many of these support tickets end in a call. The only reliable way to get all parties to solve the issue is by forcing them to get on a call and spend time actually thinking and working through the problem.
No level of docs is going to solve that human issue.
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.
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.
It’s good that Bob’s App Factory cares enough about security to hand off hard parts to Google for $X/mo if they’re not confident in their own ability to handle it better themselves. I trust Google more with my data than any other company in the world, including Bob’s. Bob’s a great guy but I doubt his IT department is reviewing every change in keycloak and preventing unilateral access to hmac keys.
But if you are a larger company who is outsourcing security, then you're subject to enterprise sales and vendors (Google excepted) who might be ridiculously incompetent. (Even if you have people on staff qualified to vet vendors of infrastructure, now you're in SaaS enterprise sales territory, where decisions aren't always rational or informed.)
And you're also looking at lots-of-eggs-in-one-basket centralized single point of failure for swaths of the country, which is a more attractive target than Bob's App Factory alone.
Example related infrastructure: https://en.wikipedia.org/wiki/SolarWinds#2019%E2%80%932020_s...
I doubt it. Once you notice how bad the median enterprise IT operation is at running an IdP the idea promotes itself.
The IdP company makes money off their security product. This means they are more likely to invest into security, because it's their business that is at stake.
Meanwhile the average company doesn't make money off a secure authentication flow. They make money from selling their SaaS product. Their goal is to spend as little on security as possible.
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.
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.
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.
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.
SSO tax is creating a lot of barriers and problems that it doesn't even realize.
Something has to give.
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.
jFrog Artifactory Enterprise license gets you SSO
Atlassian Crowd for Self hosted gets you SSO
Is this saying that you need a license to get SSO?
I have developed several SSO in-house. The various providers don't always align. e.g. sometimes you get the email, sometimes you get others, sometimes you don't get anything. It's a mess. If any of those details goes wrong, your user will be locked outside of your system and vent.
And there's another kind of fake-SSO. After the first time you login with SSO, the system asks for yourr phone or email again! So what's the point of SSO?
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.
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) ...
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).