Hacker News Reader

Comment by SkyPuncher | Hacker News Reader

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.

View on HN

> 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.

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

Sorry but that just means the feature is difficult to use on either side, so that would be at least 50% of your problem anyway. Provide good docs? How about that?

Every time someone has a problem create docs for it and after some time those questions will reduce significantly.

edit: also, for people implementing this the first time it should be obvious what happens when

1) they create a new account in your app (local)

2) if they create a new account within SSO provider

3) what happens with existing accounts during setup and if current users will be migrated over or not (or if they can use both singins)

Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities.

And customers don't necessarily read the docs, or even if they do they don't configure everything correctly.

And we're not even at customization that is particular to the customer. How to represent that in their identity provider and how to get your application to follow that in the way the customer expects.

> Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities.

no, you just provide the most used ones, once you have like top 5, that helps a lot

> And customers don't necessarily read the docs, or even if they do they don't configure everything correctly.

so just like with any other feature, really

also you should be improving docs, if they are not clear, make them clearer

it's basic sysadmin stuff, eventually 90% will understand and 10% will ask regardless of what you do, so just embrace yourself for those occasions

>also you should be improving docs, if they are not clear, make them clearer

I've written the docs with a tons review and feedback, this saying comes to mind: "Nothing is foolproof to a sufficiently talented fool"

There are no more sysadmins at most companies, it's just desktop support and maybe Office365 admin who was desktop support but got promoted because they were elite ClickOps. Powershell/Terraform, that's for those DevOps people over there and they want nothing to do with us.

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

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.

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

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.

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.

Reply on news.ycombinator.com