zlacker

>>mathia+(OP)
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+Ek
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+AQ
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.

>>bks+7T1
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?

>>manana+A82
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.

>>loik76+lM2
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.)