Vendors that treat single sign-on as a luxury feature(sso.tax)
sso.tax
Vendors that treat single sign-on as a luxury feature
https://sso.tax/
194 comments
> 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.
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.
> 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.
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.
Price discrimination allows producers to capture consumer surplus from consumers with a greater WTP than the otherwise price, and to offer the product at a lower price to those with a lower WTP.
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.
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.
There are many arguments I've heard about price discrimination being annoying, but deadweight loss is not one of them. Quite the opposite, fixed prices in the presence of undeserved pricing power results in a less than socially optimal amount of production, and price discrimination tends to reduce that.
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.
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.
[deleted]
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.
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.
> 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.
Why? eg no one questions students discounts.
Nor question non-profit discounts, or even startup discounts.
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)
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)
Framing is everything, though. See complaints around Tesla pricing for the same battery hardware with different software.
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.
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.
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.
0: https://x.com/patio11/status/1481293027331440640
> 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
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.
> 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'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 support SSO as well, and have in previous roles, and support costs did not drive SSO pricing.
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.
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.
To add an anecdote from the other perspective, I was the PM for the authn/z capabilities of a big enterprise platform.
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.
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.
If you just supported OIDC, you'd still have upcharged for it, at least unless you had an ideological reason not to (we don't, for ideological reasons, but I sort of rue that decision).
I realize in retrospect my comment was probably confusing as written.
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.
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.
But with SSO you can offload all the 2FA handling to the IdP.
Most customers did. But due to a wide variety of customer types and various hybrid auth environments, we had to support 2FA directly in-platform as well.
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.
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.
> The major identity support cost is 2FA, because people constantly lose it, and you need to design and manage an account recovery process.
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.)
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.)
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.
Except the segmentation isn't all that sharp. With Google domains et al almost everyone wants SSO now, even the smallest of companies.
It's not that small companies don't want it, it's that they're capable of not getting it. Larger companies aren't: one thing their SOC2 auditors will actually be able to evaluate is whether all their vendors do SSO.
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.
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.
> 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)...
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)...
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.
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.
We have Github Enterprise licenses for all our developers. All 7 of them.
Similar with other services.
Just because of SSO, as we don't have the manpower to handle the compliance stuff our customers demands otherwise.
Similar with other services.
Just because of SSO, as we don't have the manpower to handle the compliance stuff our customers demands otherwise.
Can you clarify, are you suggesting that the bills footed by large orgs that require SSO are paying the bills for these features?
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.
The real issue is not the first one, the issue is the 2nd and 3rd, and 10th, will all have some minor idiosyncrasy. There are other posts in this thread that discuss it more in depth - I have only enough personal experience to know that this particular stove is hot.
Yes, your 2 seat small business isn't paying the bills.
I don't think SOC2 specifically demands SSO and just encourages it. Probably good, since such security mandates often age badly, even such a broad concept like SSO could fall victim. And there is always that one tool that isn't integrated, ironically inhouse software often neglects it.
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.
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.
It doesn't specifically demand it, but (1) SSO is the simplest way to knock out a huge swath of control objectives, and (2) once you attest to a control like SSO, it's extremely annoying to pull that back. If you hire security/compliance/engineering management to take you through SOC2 and they don't set up and attest to SSO, they're bad at their job.
Security is an optional feature? You must be a sales executive...
SSO doesn't add security, it enables bulk management of accounts. Which only affects security in an indirect way.
Technically it doesn't add security, but I think the recommendation for SSO stems from the reality that peoples behavior gets worse if they have to maintain more accounts. And if they use the same password, the least secure system affects the others in a classical setup.
the human side of security, the one thats more often breached.
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.
On the other hand you have dev time that needs to save user passwords in a secure way. And this is the part of software that requirements maintenance and updates.
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.
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.
shouldn't every new company be using SSO for everything in 2025 and beyond? how long before this no longer becomes a good signal?
So the price insensitive get the security the price sensitive can’t afford.
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.
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.
You can moralize it all you want. All I'm saying is: the alternative to the SSO tax isn't that everyone gets the features they want at the price they want: it's that the price of the low-end product goes up and the price of the high-end product goes down. If you care about distributional effects, that seems like a step backwards.
That's not necessarily true. You make it sound like there are only two group. Big Enterprise with SSO and small without but there are also those small who need SSO and can't afford.
So the overall revenue and profit could be higher if they offer the SSO at the same price as without
So the overall revenue and profit could be higher if they offer the SSO at the same price as without
> but remember that the big price-insensitive customers pay for the price-sensitive customers
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?
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?
Yes - it's an enterprise versus SMB distinction that doesn't require asking questions like "What's your revenue?" in the qualification. Enterprises need it. SMBs don't.
I hate this argument. The local PTA or kids sports league or boutique needs sso as much or more than an enterprise. These may be organizations without an IT department at all, handed down from family to family, where they are transferring a database of gmail passwords. I know gsuite and office365 have free tiers for charity, but the amount of small businesses with a gmail address is staggering.
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.
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.
As someone who does a lot of local organizing, I really don't think getting SSO set up in this level of organization is a thing that happens enough to impact pricing decisions at Atlassian. Even if SSO was completely free everywhere, most of these kinds of places would still just be using a single shared account with a shared password.
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.
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.
Similar reason why there is a big price difference between DVDs and Blu-rays, and why DVDs still exist in the first place.
They still make new DVD's?
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.
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.
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.
A surprising percentage of the population cannot tell a DVD from a Blu-ray in motion at home, especially if their TV does upscaling.
Of course physical media as a whole is still way down. Streaming outearns physical by a lot. All physical media is less than half what just blu ray was 10 years ago.
Yes, so they can cover the price sensitive customers, and charge a higher price for Blu-rays for the quality sensitive customers.
I’d take it a step further and say it helps the customer filter vendors too small to be worth the trouble.
At work, I can’t afford free.
At work, I can’t afford free.
This is how I've come to accept it too
And honestly when I really really want SSO anyways, I can bolt on vouch proxy for free
And honestly when I really really want SSO anyways, I can bolt on vouch proxy for free
Wouldn't vouch proxy only work with self hosted apps? How would you use it with a SaaS app?
What are your normative views on this topic?
That there's nothing magic about security to exempt it from economics.
That's not a normative view (the hint is the "there's" which is a contraction of "there is"). A normative view would use the word should or ought.
Pretty sure I meant what I said.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[deleted]
Do you mean that you don't have a normative view on it, or that the thing you said was a normative view, or something else?
If you want to fit the word "should" in there somewhere, you can. I think SSO is important, and it would be one of the first 3 things I would stand up at any new shop I went to, but I can think of more important security things that nobody really thinks should be equally distributed across companies.
Okay:
"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.
"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.
That's not the fault of the vendor, it's the fault of the customer who refuses to pay for what the vendor charges. You couldn't argue that it would be "unethical" for Atlassian to charge $1000/seat; you'd just say it was too expensive. Somehow though, when you bundle security into that, you don't look at it and say "customers should not use the cheap-o account type and should pay what Atlassian is actually charging for this service, or use a different provider" --- no, they blame Atlassian.
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!
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!
I think as the B2B customer you ought to do right by your users. But as the B2B vendor you have a responsibility to guide your customers towards making better choices. If your SSO plan costs $1000 a month and that's the "true" cost, your non-SSO plan should cost $900 a month to make it unviable for your customers to try and make the bad choice.
This is all normative.
This is all normative.
What's a "true cost"?
I mean what the vendor actually wants to make the customer pay based on their internal margins. If the intention is to make customers pay $1000 a month, don't price a non-SSO tier at $150 a month.
Just my opinion.
Just my opinion.
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.
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.
> 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.
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.
> 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.
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.
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.
[deleted]
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!
It's evil to sell a product for a price higher than you, personally, want to pay?
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.
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.
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.
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.
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.
resource "azuread_service_principal_delegated_permission_grant" "grant" { service_principal_object_id = blah resource_service_principal_object_id = blah claim_values = ["openid"] }
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"] }
Hmm, I could swear this didn't work the last time I tried it, but that was a while ago, and it worked an absolute treat. I was probably just confused by it. Thanks for the pointer, you've made things a tiny bit better :)
[deleted]
I’m confused.
_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.
_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.
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.
i do sympathize - dealing with customers can be a nightmare sometimes.
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 :))
[0] https://workos.com
[1] https://news.ycombinator.com/item?id=22607402
[2] https://workos.com/admin-portal
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
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
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.
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.
God forbid the evil IT department just wants you to have the same username everywhere
Is there a go-to vendor/library that handles this (OIDC, SAML, SCIM) for SaaS services these days? Just like how everyone uses stripe for billing, everyone uses <vendor> for auth?
(self plug since you asked!)
WorkOS does exactly this. It's "Stripe for enterprise features."
https://workos.com
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
WorkOS does exactly this. It's "Stripe for enterprise features."
https://workos.com
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
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.
[1] https://samlshield.com/
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/
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).
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.
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.
Are there specific ID providers or protocols that are particularly difficult to support? Would it make sense to bracket out SSO further between:
- 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
- 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
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)
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.
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
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.
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.
The quality of the docs doesn't matter if the customer won't read them: "We'll set up a Teams meeting and you can tell us what to do"
mentioned those 10% sufficiently talented ;)
not sure about US, but here in center of europe we still have sysadmins and not many devoops people
not sure about US, but here in center of europe we still have sysadmins and not many devoops people
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.
Sure very smaller businesses are just cheap, but the rest want to get the most value out of that money spent. Finding and switching to alternatives with better price/performance is pretty normal I'd say.
Yeah, but the practice there is just to select on price, so I'm happy to pre-qual them out.
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.
The systems are also notoriously opaque.
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.
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.
ok, so? this is the exact BS why companies are so up the microsofts ass
even though their products are mediocre, you don't have to deal with this stuff
if you want to be competitive, get your sh*t together - this is the reason why nobody wants to bother with alternatives
if you want to be competitive, get your sh*t together - this is the reason why nobody wants to bother with alternatives
So, one of the things I didn't touch on is misaligned incentives. This creates a layer of apathy that grinds everything to a halt.
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.
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.
Well, you can just ignore all these customers? Point to the ‘SSO is self-service’ sign you have hanging above your website?
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.
You think you have it all figured out until MegaCorp walks in with an Active Directory system that originated as a "Windows NT Domain Controller" and still can't handle TLS properly.
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.
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.
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.
This comment clears things up. As setting up Google/Discord with Better Auth wasn't particularly hard for one of my home projects.
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.
A lot of premium or business plans don't offer SSO either. It's Enterprise or bust 9 times out 10
The end of the sales funnel is Enterprise, yes.
> 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.
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.
Why? It is a screaming good deal for >90% of companies to take as many problems like “employee credentials can be used to access user passwords”, “we need to develop, release, operate, and support something where small mistakes introduce security breaches + hire people capable of property doing that work”, and “if someone gets this private key they can use it to impersonate any user” off their plates as they can.
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.
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.
Agreed that sometimes it makes sense to outsource, if Bob's App Factory is big and complex enough to actually need SSO, but isn't big enough to want to run it themselves. (I was thinking more F500, which is what I did a lot of SSO work for.)
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...
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...
> Someone must have paid a lot of money to promote that idea.
I doubt it. Once you notice how bad the median enterprise IT operation is at running an IdP the idea promotes itself.
I doubt it. Once you notice how bad the median enterprise IT operation is at running an IdP the idea promotes itself.
I don't understand the problem.
The incentives seem to be aligned.
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 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.
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.
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.
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 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.
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.
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.
You can always use a passkey with your Google account.
if you need SSO you have money
if you need SSO but you don’t have money, you have issues
if you need SSO but you don’t have money, you have issues
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.
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.
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...
[deleted]
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).
This is the most security-aligned approach - storing credentials creates significant liability (breach risks, compliance requirements, password rotation policies) while offloading authentication to specialized providers reduces attack surface and improves user experience.
If you ran a saas, you'd know how much more supporting SSO costs and sing a different tune.
This is a real problem of misaligned incentives.
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.
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.
Just to add to this, a lot of those businesses in those industries are NOT in "IT", and have awful Operational Technology networks and security, yet their business as a chemical supplier, or shipping company, or finished materials producer, or even a small regional ISP is both "critical" to the country, and yet lucky to even have a handful of staff looking at "IT" or security.
SSO tax is creating a lot of barriers and problems that it doesn't even realize.
Something has to give.
SSO tax is creating a lot of barriers and problems that it doesn't even realize.
Something has to give.
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.
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.
At Budibase, we give away SSO for free. Putting a price on security felt wrong.
https://github.com/Budibase/budibase
https://github.com/Budibase/budibase
Guilty as charged. With BrowserBox I will be adding an SSO layer. Enough people ask for it. And it's not that hard to add something basic that customers can extend.
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.?
[0] https://audit-logs.tax/
[0] https://audit-logs.tax/
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...
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).
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.
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.
That's why single sign on is so great, every single vendor has their own way of implementing it.
And then if you need multi-tenant...
I don't care about most of the 60 features in an Enterprise Plan for $20,000/mo or whatever, what I need is fucking SSO for the sub-100 or sub-500 count shops. Ugh
A little confused on this
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?
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 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.
as others have pointed out, it's not a tech issue, it's a support cost.
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?
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?
SSO is actually really annoying to implement well.
Better cash up
Better cash up
That list of firms is a wall of shame, period
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.
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.
thank you for this. i also found this few years back, incredibly annoying.
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) ...
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 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.
in the real world you pay for extra security; yet developers think that this should be free just cuz…?
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).
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.
DamnNear. Every. Customer. Needs. SSO.
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