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.
> 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.
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.
Most of the big players like Microsoft charge enterprise customers for support on top of everything else. And this "premium support" still sucks. Microsoft outsources to Accenture who then outsource again to some random dopey small companies in the middle East so you get calls in the middle of the night from Qatar by someone who has no more knowledge than what the docs say. Which you've already read yourself otherwise you wouldn't have gone through the hassle of logging a ticket. Because outsourcing causes barriers between the people who built the thing and the people who support it.
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.
Many "softer" forms of SSO have trickled down too. Google + Microsoft OAuth are ubiquitous today without any upchage. OAuth from a Google Workspace account managed by an IT admin has many of the same security guarantees as SAML or OIDC from a Google Workspace account, at least for a small player. There are some sketches like https://easie.dev/ that explore this further.
Also, enterprise customers are way more work, the sales cycle is longer, the compliance and onboarding stuff takes more time. There's a very legitimate case for building that into one's pricing, and it's really the same reason these companies appear price insensitive. If they had people lining up to give them a better price, they'd presumably take it.
> 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.
I ran a company that did price segmentation on SSO, and it's the other way around. The burden of supporting the buggy piece of crap that is SAML SSO is the cost of the privilege of being able to perform such sharp segmentation.
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.
It's segmented even in OSS software to the point where it's the first thing I have to check when deciding what software is going to run on my home server.
I run a very small business, SSO is still very high up on my feature priority list, and I have passed on software/services I would have otherwise used for competitors that offered SSO at a lower entry-point.
> 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)...
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.
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.
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.
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")
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.
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.
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.
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.
> 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.
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.
Sure sounds like you haven’t done SSO operations for a large SaaS provider. Because it’s much, much more support and engineering work to integrate every random SSO provider, each with wildly customized differences for each customer, all totally opaque to the application provider, versus just having a single unified login system that your support staff has necessary visibility into.
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.
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!
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.
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.
_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.
I will say that most of the consumers of SaaS SSO solutions in our experience are the lowest bidding MSPs the customer can find or some oursourced operation. They usually employ the lowest paid fuckwits who play pass the blame around as long as possible and expect the supplier to prove every issue isn’t them.
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.
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.
>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
My hot take is that the SSO tax is totally legitimate because SSO is a clunky and complex feature to manage in a secure way. In fact many SSO implementations are actually not that secure because SAML is a dumpster fire when it comes to security vulnerabilities.
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.
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.
> 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.
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)
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.
> 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
>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.
Yeah, but in the center of Europe, customers are very price sensitive so you only target them once you've got adoption in the customers who can pay. Have to industrialize your processes before the cheap people are worth it and that takes time in startups.
The necessary docs are for the SSO system. So while we can build the docs, those UIs change often and without notice, and each customer may see something different, depending on their individual config or permissions. It’s literally impossible to “just provide better docs” consistently without incurring heavy expense… thus the extra cost.
Nah, SSO is a huge pain in the ass, and the variation in identity providers doesn't make it worth it. Everyone thinks they can write foolproof docs but either they're so slow that you lose the market, or they can't actually do it.
You really need to listen to the folks who have expertise in this area. It’s not this simple. Nowhere close. Take just Google users or Entra users, and there are variations between almost every single one, and they all require handholding and multiple back and forth manual steps to configure. And if anything goes wrong in the future they are impossible to troubleshoot.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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).
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.
Does anyone know of a list/can name companies that don't charge for SSO, Audit Logs[0], that have a free edition where you don't have to talk to a salesperson to evaluate etc.?
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.
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.
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...
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).
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.
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.
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.
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.
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).
... 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)
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.
0: https://x.com/patio11/status/1481293027331440640
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.
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)...
At work, I can’t afford free.
And honestly when I really really want SSO anyways, I can bolt on vouch proxy for free
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.
_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.
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"] }
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.
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.
[1] https://samlshield.com/
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
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.
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.
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.
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.
[0] https://audit-logs.tax/
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.
Better cash up
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) ...
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).