Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An admittedly wandering defense of the SSO tax

ssoready.com

Post reply on HN
Print view View original

31–40 of 99 posts

Re: An admittedly wandering defense of the SSO tax

#31

Post by greenstreet1994 »

ned_at_codomain wrote: post #25
grinich wrote: post #23

Earlier quoted context omitted.

The “human cost” of SSO is definitely the hardest part. At WorkOS we solved this by shipping the whole config workflow in the form of an admin portal. It checks things like SAML certificate, signatures/assertions, attribute mapping, etc. and a zillion other edge cases across dozens of identity systems. It’s pretty much “Stripe Checkout" for setting up SAML. Live demo here (click “Configure”) https://explore.workos.co…

Oh cool! We have pretty much the same thing

how is yours different? curious to know

Re: An admittedly wandering defense of the SSO tax

#32

Post by commandar »

SOLAR_FIELDS wrote: post #21

The reality is much simpler than the article would have you believe. The article goes through all these convoluted explanations about value add but the simple fact of the matter is that SSO is the one differentiator that businesses will guarantee pay for. The other features are often unknown to stakeholders outside of the internal champion and need explanation oftentimes. But SSO, enterprises always need at a certain…

I'm in the healthcare world.

SSO is a hard requirement for us.

There have been many, many times where we've considered an application where we could justify the spend at, e.g., the departmental level for the limited user base that needed it, but where SSO being bundled into higher price tiers combined with minimum user counts took a potential solution from "very easy discretionary spend" to "not happening, full stop."

I'm often the one having to make these decisions. It's absolutely exhausting having to explain to non-technical department heads that "yes, this would solve your problem at a price that fits budget, but the vendor bundles a vital security feature into a tier that inflates the price to a point that it makes this unfeasible."

Re: An admittedly wandering defense of the SSO tax

#34

Post by icambron »

I don’t really mind paying for SSO. It’s fine. But I hate that it’s the one feature in the “enterprise” tier that I need, and now I have to talk to a sales rep and sign a contract. You could have just charged me more per seat and it would have been better for both of us. Instead I looked for another vendor that didn’t let their sales team convince them to let the AEs gatekeep a basic feature.

Re: An admittedly wandering defense of the SSO tax

#35

Post by ivan_gammel »

I was responsible for IT in a hypergrowth scale-up and I don’t like this article, it misrepresents the problem. The problem is, when you are big enough to set up SSO like Okta, you have to upgrade nearly all of your subscriptions in a short time to make use of it, suddenly resulting in a huge increase in the budget. So, let’s say the business goes from X to 2X in revenue and from X to almost 2X in staff (let’s assume there’s some small increase in productivity over time). In some incredible logical twist every SaaS provider thinks that 2X increase in price is affordable, despite that the company is still burning money and the enterprise features aren’t really needed yet. 2X budget isn’t approved by CFO, cost-cutting exercise starts and price increase is matched by significant reduction in number of licenses. Did it worth it? Not sure. Volume-based pricing complimented by feature add-ons would do a good job too.

Re: An admittedly wandering defense of the SSO tax

#36

Post by dakial1 »

This is the same way all airlines in the world work since the invention of Revenue/Yield Management. Which is basically price discrimination to get the biggest piece of the value.

Airlines will mostly segment client based on things like Minimum Stay (in destination) and how many days before the flight the ticket was bought to find the most desired of all users: The business traveler.

SSO is (roughly) the same thing, companies who would like SSO are probably the ones in the corporate level, and this is an efficient way to find them. Of course there are false positives, but software companies are willing to live with those to get the biggest part of the pie.

And this is actually good for users, as it allows for the other users who have more flexibility to pay a lot less (both at airlines and software) than they would pay if those companies didn't discriminate.

Re: An admittedly wandering defense of the SSO tax

#37

Post by DaiPlusPlus »

ned_at_codomain wrote: post #7
wmf wrote: post #3

This car with no seat belts, no airbags, and no ABS is just price discrimination! Strangely, no one seems interested in celebrating the implied discount for not having safety.

This is a solid objection that I hadn't considered before! Why isn't SAML SSO mandated (either literally or my convention)? Practically speaking, as someone who spends all day trying to convince developers to implement SAML SSO, I really wish this were the case :) I think in practice, software vendors correctly assess that relatively few of their prospective customers actually care. If many small / price sensitive co…

> Why isn't SAML SSO mandated

SAML isn't exactly the best choice here. It's very SOAP-y; that's like being in 2005 and mandating everyone use SOAP+RPC for interopability.

Re: An admittedly wandering defense of the SSO tax

#38

Post by Terretta »

This argument misses the mark that SSO tax is charging extra for a practice that: (a) BnL everyone should do, (b) reduces the SaaS provider's liability, (c) is incredibly costly to change/transition how it's done after initial setup, (d) actually doesn't add much overhead when using poor-man's SSO aka OIDC/OAuth2* (the now ubiquitous "sign in with" or "continue with" buttons that require zero integration once set up once), (e) drags in a host of other odious interactions most buyers want nothing to do with (Call Us? Why?), and (f) is bad for industry trust as a whole.

Also, people wouldn't even mind if you added $2/user so you can't lose their creds and they don't have to remember your password. (For comparison, all of Microsoft E5 security tools together add ~$20 to M365.)

If you really want a differentiator they have to pay for that isn't SSO, go with "audit logs", "RBAC", and "Team Roles" management as lifts. Most anyone required to use SSO is required to use vendors that support audit logs. For SSO itself, you can also still charge for "automated group provisioning" (what used to be SCIM in SSO world). By the time they care about teams, they care about this.

See more features to charge for here: https://www.enterpriseready.io/

* This is on top of the argument from elsewhere in this thread, "Use our Google login then..." Note to the B2B startup bubble: more of your potential small, mid, and Fortune 500 business customers (where customer headcount > 1) can "Sign in with" Microsoft than Google. (Some estimates put it at 85%). Meanwhile, what startups and businesses on each side of B2B think they need legacy SSO/SAML for, most can actually meet all their requirements with this far more straightforward approach combined with a domain name control check and email domain filter.

Re: An admittedly wandering defense of the SSO tax

#39

Post by philipwhiuk »

This a terrible defence.

The reason there's a belief of an SSO tax is not that you have to pay more to get SSO, it's that companies use SSO to get you to pay for features no-one ever wanted but they did a lot of development on because they know you need SSO.

And the gatekeeping of it behind sales people.

Re: An admittedly wandering defense of the SSO tax

#40

Post by sethops1 »

candiddevmike wrote: post #24
sparrish wrote: post #8

Earlier quoted context omitted.

This is the real reason there's an SSO tax. It costs to support SSO, the customers who want SSO should pay for that cost.

There are plenty of folks who setup SSO with open source projects without a support contract. Why should they have to pay for it with other software?

Because the engineers of the other software chose not to work for free?
Post reply on HN