zlacker

For those wondering what the "SSO Tax" is, it refers to the excessive pricing practiced by SaaS providers to access the SSO feature on their product.

A documented rant has made the rounds at https://sso.tax , which lists all vendors and their pricing of SSO.

>>kdeldy+(OP)
I always thought this was insane, but now I wonder if "SSO Pricing"/tax is just the "real price" and the "Base pricing" is really the new free trial? Of course the SSO/real pricing is too high, and everyone negotiates it down, but the point is I suspect the "base pricing" is just a trial teaser that's probably not sustainable for many vendors in terms of margins. I'm just guessing here, maybe someone with some inside insight from one of these vendors can advise.

>>pwarne+Wv
I'd rather consider it "SME pricing" vs "Enterprise pricing". Typically only companies above a certain size use SSO systems, and even larger ones require it for everything. Coincidentally bigger companies are also willing to pay more, so putting a high price on SSO enables SaaS to profit from those deep pockets without pricing themselves out of the market for smaller companies.

>>wongar+gL
Schools, colleges, and universities typically have SSO but no budget or purchase authority.

>>westur+MR
Just slap an education discount on it and call it a day. There are plenty of reasons to do that anyway, you want students to get trained on your software and use it in their formative years as much as possible.

Many go even further and just give the product away for free for educational institutions and individual students (Github, Jetbrains and Tableau come to mind as examples)

>>wongar+0V
For a small-scale implementation in a university, open core without SSO is no-go: nobody has any money or purchase authority.

>>wongar+gL
> Typically only companies above a certain size use SSO systems, and even larger ones require it for everything.

I believe it's historically grown but it's not true anymore. More companies would use it if they could as this makes your processes way more automated, easier and more secure. Also more companies take security seriously (i.e. more and more companies get ISO27001/SOC2 compliant) but just can't afford the Enterprise prices.

>>pwarne+Wv
Great question, and as a vendor with multiple products that suffer from an SSO tax here is my $.02

As a small team we get constant requests to integrate with a customers SAML provider - eventually we just switched to https://workos.com/pricing We explain to our customers that we have a hard cost for the integration and we pass that cost to them directly. The SSO version of our product and our self signup product do the same thing the same way - it's the compliance or risk management requirement mandated by our customers that require that we sell it the way we do. In our case our SSO or Enterprise version is $125 more expensive than the self signup product. Our money is in the product itself not in the SSO.

>>wongar+gL
Things like Google Workspace et al. make it super easy to use SSO (ok a bit difficult but usable) even for smaller companies and honestly it should be used by basically everyone as a core security practice. It's annoying that companies charge out the rear end for a basic security feature. It'd be like charging to let people use 2FA/security keys.. just super stupid/arrogant.

>>bks+ty1
So, uh, is that cost a “SAML is a compatibility minefield and requires constant tweaking” cost or a “we need to allocate some of our people to figure out the network setup together with yours” cost? Or something else entirely?

>>kdeldy+(OP)
SSO: Single Sign On

Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.

SCIM: System for Cross-domain Identity Management

System for Cross-domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems.

SAML: Security Assertion Markup Language

Security Assertion Markup Language (SAML, pronounced SAM-el, /ˈsæməl/)[1] is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.

https://en.wikipedia.org/wiki/Single_sign-on

https://en.wikipedia.org/wiki/System_for_Cross-domain_Identi...

https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...

(if you work at SpaceX, SSO might also mean Single Stage to Orbit, which is lots more exciting - but since Elon banned acronyms maybe it's not used)

>>bks+ty1
Great approach. Wish there would be more vendors like that. This way we wouldn't even need to talk about SSO-Tax, availability of SCIM/SAML etc.

>>kdeldy+(OP)
Thanks, I was wondering what "SSO tax" means. I see it differently. The enterprise plan is that the company really wants to sell. But it gives a discount to small companies that don't need the enterprise features like SSO, at least not from the beginning. I think it is very similar to freemium pricing - extra features, extra cost. Of course, when I look at a product, I look at all the plans and decide if it is worth the money now and in the future. I may feel pity and not buy it. But I never blame companies just for their pricing page.

>>wongar+gL
And of course part of why SMEs don't use it or don't use it everywhere is that suppliers make it much more expensive to do that because they insist security is only for Enterprise customers.

>>wongar+gL
Of course small companies don't use it, because it is outrageously expensive.

>>wongar+gL
That may have made sense 5-10 years ago. Todays expectations on security and convenience are very different.

Everybody deserves sso, regardless of size of company.

With the rise of micro services and DevOps, the number of applications used in an org has also exploded, adding even more reason to use SSO. Paying such big markup for every one of them is not sustainable for an SME.

>>manana+WN1
it's most likely "we couldn't be bothered to implement saml in-house or use one of the many existing libraries, so we punted it of to okta"

saml has annoyances, but it doesn't have so many annoyances that every customer needs to be a custom integration. the majority of users using saml are going to be coming from a handful of idps, typically adfs or google.

>>kdeldy+(OP)
Thanks for the useful link. The introduction says "like Google", but the table does not list Google pricing for SSO.

We use Google SSO at work, but I am just a user. Not involved either budgetwise or implementationwise.

>>loik76+Hr2
re: "we couldn't be bothered to implement saml in-house" This is NOT nearly as simple at that statement lays it out to be.

I am also from a SaaS vendor and we are using a 3rd party to integrate to the various SSO providers our customers have. We have not tacked on any additional cost to our customers for this as we also believe this to be baseline. But I do like the approach of at least covering costs.

For us it was not a matter of "not being bothered to implement saml in-house". We carefully considered our options. However, implementing it ourselves means we must have an in house expert on SAML and understanding the various IDPs.

It also requires someone to tightly monitoring any security issues that may appear in the wild that could impact our implementation. (We do still need to keep our eyes open, but we can leverage our vendor for help here.)

Resources required to this ourselves is a minimum of at least 1 full time engineer and someone who can be their backup, we need additional testing resources, and more. Making this roll < full time will hurt you down the road.

I'd rather our people can be focused on the problems our product is built to solve for our customers and then we can work with experts in the SSO space to guide / help us in solving that problem.

On the other hand: the 3rd party we're working with likes to come back every few months with a "Oh! We didn't know you were going to do (fill in the blank), we need to add another dollar per user per month for that."

Neither approach is perfect. But I lean towards keeping our teams as focused as possible on our product.

(PS: I have been with other orgs who've done SAML in house, and it is not simple. Don't underestimate it. It hurt, and we burned a lot of resources that could of been making our product better.)

>>detaro+Xf2
That means they can live without it. Enterprises can't so they pay for it. Making customers pay for what they need is reasonable. Sure, everybody would like to have every feature for free...